Author Topic: gh_vertex_pool.render parameter count wrong?  (Read 9200 times)

0 Members and 1 Guest are viewing this topic.

groundhog

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
gh_vertex_pool.render parameter count wrong?
« on: November 05, 2015, 09:56:15 PM »
hi!

The reference gives "gh_vertex_pool.render(vp, 0, -1)" as example, but when using it in python I get
"function takes exactly 2 arguments (3 given)"

What changed?

regards

G

Edit:
And "gh_vertex_pool.vb_map(vp)" from the documentation is now called "gh_vertex_pool.map_vb(vp) in python. Same for unmap.
Is the python binding still actively supported?
« Last Edit: November 06, 2015, 10:49:17 AM by groundhog »


JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #1 on: November 06, 2015, 01:49:19 PM »
Thanks for your feedback, indeed, the recent changes I did in the Lua API are not available in the Python plugin.

gh_vertex_pool.render() has 3 paramerters, the last being the number of particles to render.
The current python function has only two and does not work because the number of particles is set to 0.

And yes, gh_vertex_pool.vb_map() and vb_unmap() are the correct names.

I updated the Python plugin, it will be released as soon as possible. If you are on Windows, I can send you a test version quickly.


groundhog

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
Re: gh_vertex_pool.render parameter count wrong?
« Reply #2 on: November 06, 2015, 02:08:30 PM »
So I am posting here instead of continuing private messages:

Sorry I forgot to tell you that GeeXLab uses new prefix for Lua and Python functions: "gxl_". But the "gh_" prefix is still available and it's a bug in GeeXLab with the Python plugin.

I will check the vertex_set_position() and .vertex_get_position() functions.

If you want to mix Lua and Python you can do it (and you can use shared variables to communicate between Lua and Python, check the gh_utils.shared_variable_xxxx() functions) but you don't have to do it because the Python plugin has some bugs. I have to fix them!

For next bug-reports and discussions, please use the forum, it's useful for other users  ;)

I'm fixing the bugs...

I fixed the bug with the prefix (gh_ or gxl_). If the XML root node is glsl_hacker, the lib prefix is gh_ and if XML root node is geexlab, the prefix is gxl_.

Indeed, there was a bug in vertex_pool.vb_set_vertex_position() (as well as in all vertex_pool.vb_set_vertex_xxxx()).

To write a trace, just use utils.trace().

Let me know.

Hm. Still not able to get it to work. Am I doing something wrong?
I tested all combinations:
Code: [Select]
vp = gxl_vertex_pool.create(num_particles)
gxl_vertex_pool.vb_set_vertex_position(vp, 17, 1.1, 2.2, 3.3, 4.4)
gxl_vertex_pool.vertex_set_position(vp, 19, 2.1, 3.2, 4.3, 5.4)
(x, y, z, w) = gxl_vertex_pool.vertex_get_position(vp, 17)
(x1, y1, z1, w1) = gxl_vertex_pool.vb_get_vertex_position(vp, 19)
(x2, y2, z2, w2) = gxl_vertex_pool.vertex_get_position(vp, 19)
(x3, y3, z3, w3) = gxl_vertex_pool.vb_get_vertex_position(vp, 17)

gxl_utils.trace('<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<')

gxl_utils.trace("X={:f}, Y={:f}, Z={:f}, W={:f}".format(x, y, z, w))
gxl_utils.trace("1: X={:f}, Y={:f}, Z={:f}, W={:f}".format(x1, y1, z1, w1))
gxl_utils.trace("2: X={:f}, Y={:f}, Z={:f}, W={:f}".format(x2, y2, z2, w2))
gxl_utils.trace("3: X={:f}, Y={:f}, Z={:f}, W={:f}".format(x3, y3, z3, w3))

Output is:
Code: [Select]
2015/11/17@11:23:57(0000000143) < >  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2015/11/17@11:23:57(0000000144) < >  X=0.000000, Y=0.000000, Z=0.000000, W=1.000000
2015/11/17@11:23:57(0000000145) < >  1: X=0.000000, Y=0.000000, Z=0.000000, W=0.000000
2015/11/17@11:23:57(0000000146) < >  2: X=2.100000, Y=3.200000, Z=5.400000, W=1.000000
2015/11/17@11:23:57(0000000147) < >  3: X=0.000000, Y=0.000000, Z=0.000000, W=0.000000

G
« Last Edit: November 17, 2015, 11:26:32 AM by groundhog »

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #3 on: November 17, 2015, 12:28:32 PM »
oops, I didn't see your post.
Let me check.

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #4 on: November 17, 2015, 01:09:22 PM »
If you need to set the position of particles once (in an INIT script for example), use that code:

Code: [Select]
num_particles = 100
vp = gh_vertex_pool.create(num_particles)

for i=0, num_particles-1 do
    local x = ...
    local y = ...
    local z = ...
    gh_vertex_pool.vertex_set_position(vp, i, x, y, z, 1)
end


You can also use gh_vertex_pool.vertex_set_position() in a FRAME script.

If you need to update the position more frequently (FRAME script), you can update the position of particles in GPU memory with GPU mapping:

Code: [Select]

num_particles = 100
vp = gh_vertex_pool.create(num_particles)

gh_vertex_pool.vb_map(vp)

for i=0, num_particles-1 do
    local x = ...
    local y = ...
    local z = ...
    gh_vertex_pool.vb_set_vertex_position(vp, i, x, y, z, 1)
end

gh_vertex_pool.vb_unmap(vp)

Both methods work in an INIT or FRAME script.


groundhog

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
Re: gh_vertex_pool.render parameter count wrong?
« Reply #5 on: November 17, 2015, 01:22:25 PM »
Yes, but why does the related GET_... not work?
As you can see in my post above, it returns either nothing or the position in scrambled order with W=1.

G

If you need to set the position of particles once (in an INIT script for example), use that code:

(...)
Both methods work in an INIT or FRAME script.

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #6 on: November 17, 2015, 01:54:43 PM »
I will code a little demo in Python to check your issue. I let you know asap.

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #7 on: November 17, 2015, 04:01:59 PM »
I found another bug in gh_vertex_pool.vertex_set_position() and gh_vertex_pool.vertex_set_color().

Now the grid deformer demo works fine in Python.


In your code, you mix vb_set_vertex_position and vertex_get_position:

gh_vertex_pool.vertex_set_position() writes to CPU memory and gh_vertex_pool.vertex_get_position() reads from CPU memory.

gh_vertex_pool.vb_set_vertex_position() writes directly to GPU memory and gh_vertex_pool.vb_get_vertex_position() reads from GPU memory.

That's why the position you have written with gh_vertex_pool.vb_set_vertex_position() can't be read with gh_vertex_pool.vertex_get_position().

I will release a new geexlab asap (today I hope).




groundhog

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
Re: gh_vertex_pool.render parameter count wrong?
« Reply #8 on: November 17, 2015, 05:05:50 PM »
I found another bug in gh_vertex_pool.vertex_set_position() and gh_vertex_pool.vertex_set_color().

Great! Does this fix the scrambled order of the position components?

In your code, you mix vb_set_vertex_position and vertex_get_position:

gh_vertex_pool.vertex_set_position() writes to CPU memory and gh_vertex_pool.vertex_get_position() reads from CPU memory.

gh_vertex_pool.vb_set_vertex_position() writes directly to GPU memory and gh_vertex_pool.vb_get_vertex_position() reads from GPU memory.

That's why the position you have written with gh_vertex_pool.vb_set_vertex_position() can't be read with gh_vertex_pool.vertex_get_position().

Yes, I was just trying all combinations. But vb_set/get_... alone was not working, either.

G

JeGX

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1894
    • View Profile
    • Geeks3D.com
Re: gh_vertex_pool.render parameter count wrong?
« Reply #9 on: November 17, 2015, 09:09:45 PM »
Great! Does this fix the scrambled order of the position components?

Yes, the issue should be fixed.