gh_vertex_pool.render parameter count wrong?

[groundhog]

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?

[JeGX]

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]

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 Expand


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 Expand


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

[JeGX]

oops, I didn't see your post.
Let me check.

[JeGX]

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

Code Select Expand


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 Expand



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]

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]

I will code a little demo in Python to check your issue. I let you know asap.

[JeGX]

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]

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]

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

Yes, the issue should be fixed.