BallZ
Moderator: Moderators
value editing in Ballz
I'm a complete newbie to ZGE, I just discovered it via FL Studio 9.9 beta. I quickly realized that Ballz would be a great program to study. However, as I try to edit the parameters, such as rotating the mesh, or making the ballz larger or smaller, nothing changes. I was able to change the OnUpdate->Timer to 60 seconds. What am I doing wrong? Is something locked that needs to be unlocked or what? Fascinating program!
Thank you
Thank you
Hi senji and welcome to the ZGE-forums.
BallZ is quite an advanced script and maybe not the best to start with
ZGE is also a bit different from other tools and has a learning curve but once you get over that you can do pretty powerful things like all the ZgeViz scripts demonstrates.
Try Kjells Video Tutorials. Check out the simple sample projects such as ZPong (included in the download). Also the ZgeViz development documentation.
BallZ is quite an advanced script and maybe not the best to start with
ZGE is also a bit different from other tools and has a learning curve but once you get over that you can do pretty powerful things like all the ZgeViz scripts demonstrates.
Try Kjells Video Tutorials. Check out the simple sample projects such as ZPong (included in the download). Also the ZgeViz development documentation.
@Rado1
Your BallZ visualizer made it in the official FL Studio 10 trailer ( check the 5 minute mark )
http://www.youtube.com/watch?v=OfMJkVd6Ffg
Good job!
K
Your BallZ visualizer made it in the official FL Studio 10 trailer ( check the 5 minute mark )
http://www.youtube.com/watch?v=OfMJkVd6Ffg
Good job!
K
After quite a long time I returned to BallZ screen saver because I wanted to make some more experiments with OpenGL. Attached you will find BallZ 2 with:
- better looking balls rendered by GLSL point sprites
- usage of "scalable" font with alpha test for rendering time
- some more shapes; see screenshots
- more effective computing of positions, colors and sizes
My main motivation was to improve performance; it has changed from original average ca. 120 FPS to new average ca. 220 FPS. Not too much because the most of the time still taken by computations, but there's some improvement. Another motivation was learning point sprites which I want to use for 3d particles in future.
I attached also ZGE project file for your inspiration and also ...
... I'm not fully satisfied with usage of OpenGL vertex arrays. For instance, calling glVertexPointer() and glColorPointer() on each rendering does not seem to be optimal. For Kjell (and similar people knowing OpenGL much better than me): could you please have a look at the current implementation and try to help me to optimize it? Thank you in advance.
Any comments are welcome!
- better looking balls rendered by GLSL point sprites
- usage of "scalable" font with alpha test for rendering time
- some more shapes; see screenshots
- more effective computing of positions, colors and sizes
My main motivation was to improve performance; it has changed from original average ca. 120 FPS to new average ca. 220 FPS. Not too much because the most of the time still taken by computations, but there's some improvement. Another motivation was learning point sprites which I want to use for 3d particles in future.
I attached also ZGE project file for your inspiration and also ...
... I'm not fully satisfied with usage of OpenGL vertex arrays. For instance, calling glVertexPointer() and glColorPointer() on each rendering does not seem to be optimal. For Kjell (and similar people knowing OpenGL much better than me): could you please have a look at the current implementation and try to help me to optimize it? Thank you in advance.
Any comments are welcome!
- Attachments
-
- BallZ2.zip
- ZGE project, (optional) config file and screensaver
- (133.67 KiB) Downloaded 735 times
-
- screenshots
- scr.png (313.68 KiB) Viewed 24074 times
Hi Rado1,
Concerning speeding up your CPU computations .. you might want to inline your functions, use 1D arrays ( instead of 2D ) and go with plain floats instead of vectors. Or if you want to go all out, you could do the computations on the GPU by rendering them to a frame ( floating-point ) or feedback buffer.
K
Those calls cannot be avoided ( since you're also using RenderText ) .. but it's probably ( depends on the driver implementation ) faster to allocate a VBO and update it each frame using glBufferSubData. Also, you could try to interleave the position & color attributes to get the required data per vertex closer to each other .. in which case you'd want to pad / include the w-coordinate for your position attribute to make sure the data is aliased nicely.Rado1 wrote:I'm not fully satisfied with usage of OpenGL vertex arrays. For instance, calling glVertexPointer() and glColorPointer() on each rendering does not seem to be optimal.
Concerning speeding up your CPU computations .. you might want to inline your functions, use 1D arrays ( instead of 2D ) and go with plain floats instead of vectors. Or if you want to go all out, you could do the computations on the GPU by rendering them to a frame ( floating-point ) or feedback buffer.
K
Thanks Kjell for your valuable ideas. See my comments below.
I tried this already but observed no performance improvement. That's probably because I need to update client-side memory each render pass and pass it to server side. I finally decide to remove VBOs to simplify the code. What would help is glMapBuffer, but this is not available in ZGE since it's not possible to treat pointers as arrays.Kjell wrote:.. but it's probably ( depends on the driver implementation ) faster to allocate a VBO and update it each frame using glBufferSubData.
I tried glInterleavedArrays() with GL_C3F_V3F format, but there was no space for ball size. I could not find a better format. Is there some way I could use interleaved arrays?Kjell wrote:Also, you could try to interleave the position & color attributes to get the required data per vertex closer to each other .. in which case you'd want to pad / include the w-coordinate for your position attribute to make sure the data is aliased nicely.
Do you mean, for instance, interpolate() function which is used quite often? That's pity that ZGE does not provide inline functions.Kjell wrote:Concerning speeding up your CPU computations .. you might want to inline your functions,
Does it really help? I'm not creating vectors on the fly. Is not a vector just a sequence of floats?Kjell wrote:use 1D arrays ( instead of 2D ) and go with plain floats instead of vectors
That's really interesting idea! Do you have some hint how to do it in my case?Kjell wrote:Or if you want to go all out, you could do the computations on the GPU by rendering them to a frame ( floating-point ) or feedback buffer.
I haven't tried the new version yet but it looks really nice judging by the images you posted.
How do you come up with ideas for all these cool formations?
Computing it all on the GPU could be very fast of course but based on my experience that is pretty difficult to make compatible between GPU drivers. Btw, ZGE should support ComputeShader as a component at some point.
Inline functions is something I hope to add to ZGE.
For expressions that is performance critical you could try avoiding functions that allocate memory, i.e. "vector2/3/4" will allocate memory that needs to be garbage collected. Using string-type also allocates memory.
How do you come up with ideas for all these cool formations?
Computing it all on the GPU could be very fast of course but based on my experience that is pretty difficult to make compatible between GPU drivers. Btw, ZGE should support ComputeShader as a component at some point.
Inline functions is something I hope to add to ZGE.
For expressions that is performance critical you could try avoiding functions that allocate memory, i.e. "vector2/3/4" will allocate memory that needs to be garbage collected. Using string-type also allocates memory.
Hi Rado1,
K
In that case your driver probably keeps the memory allocated for the vertex arrays on the GPU intact across framesRado1 wrote:I tried this already but observed no performance improvement.
If for instance you have a float array that contains interleaved 2D positions + 2D texCoords, you can simply use for example ..Rado1 wrote:Is there some way I could use interleaved arrays?
Code: Select all
glVertexPointer(2, GL_FLOAT, 16, myArray[0]);
glTexCoordPointer(2, GL_FLOAT, 16, myArray[2]);
Any function call adds a couple of additional cycles. It's a matter of size VS speed ( and ZGE usually leans towards small size ).Kjell wrote:Do you mean, for instance, interpolate() function which is used quite often?
Actually, i just double-checked by benchmarking floats VS vectors and there's not much difference. My badRado1 wrote:Does it really help? I'm not creating vectors on the fly. Is not a vector just a sequence of floats?
I posted a lame / simple example of this principle here.Rado1 wrote:That's really interesting idea! Do you have some hint how to do it in my case?
K
I thought myArray[2] returns 3-rd element of array by value, not a pointer to the 3rd element. I would be happy if it worked as in C, but...Kjell wrote:If for instance you have a float array that contains interleaved 2D positions + 2D texCoords, you can simply use for example ..Code: Select all
glVertexPointer(2, GL_FLOAT, 16, myArray[0]); glTexCoordPointer(2, GL_FLOAT, 16, myArray[2]);
I'm going to have a look at it. Thanks!Kjell wrote:I posted a lame / simple example of this principle here
That's my experience too. Drivers have become very clever and many techniques that was previously faster now make almost no difference in practice.Kjell wrote:In that case your driver probably keeps the memory allocated for the vertex arrays on the GPU intact across framesRado1 wrote:I tried this already but observed no performance improvement.
Hmm,
K
Depends on the GPU / manufacturer .. if you're using a Intel GPU for example, not so muchVilleK wrote:Drivers have become very clever and many techniques that was previously faster now make almost no difference in practice.
It's the same as in C .. but without the address-of ( & ) operator in front.Rado1 wrote:I would be happy if it worked as in C
K
Kjell,
I tried interleaved arrays again and performance was slightly improved by ca. 10-20 FPS; nothing special, but it works. I have a problem now when trying to use interleaved vertex array with VBO. My data structure is, symbolically speaking, <vec4 position, vec4 color>. How to specify offsets relative to the start of the buffer object for the pointer (last) parameter of glColorPointer() function? In C I would write "(GLubyte*) NULL + 16". I can use "null" for the glColorPointer() because it is the first value in interleaved array. Any idea? Of course, the simplest solution is to use two VBOs, one for position and another one for color and size. Is is the only solution in ZGE?
FYI I re-tested BallZ with two non-interleaved VBOs and its performance is really identical to original version without VBOs and two non-interleaved VAs on AMD FirePro M2000. So VA interleaving helps better than VBOs on my GPU.
I tried interleaved arrays again and performance was slightly improved by ca. 10-20 FPS; nothing special, but it works. I have a problem now when trying to use interleaved vertex array with VBO. My data structure is, symbolically speaking, <vec4 position, vec4 color>. How to specify offsets relative to the start of the buffer object for the pointer (last) parameter of glColorPointer() function? In C I would write "(GLubyte*) NULL + 16". I can use "null" for the glColorPointer() because it is the first value in interleaved array. Any idea? Of course, the simplest solution is to use two VBOs, one for position and another one for color and size. Is is the only solution in ZGE?
FYI I re-tested BallZ with two non-interleaved VBOs and its performance is really identical to original version without VBOs and two non-interleaved VAs on AMD FirePro M2000. So VA interleaving helps better than VBOs on my GPU.
Last edited by Rado1 on Tue Jul 14, 2015 9:51 pm, edited 1 time in total.
Hi Rado1,
K
Either change the "xptr pointer" argument in the various pointer-related functions ( glVertexPointer / glTexCoordPointer etc. ) to "int pointer" and pass the offset as a plain literal .. or ( when you want to keep the argument as xptr ) use the following syntax:Rado1 wrote:How to specify offsets relative to the start of the buffer object for the pointer (last) parameter of glColorPointer() function?
Code: Select all
// For example a vec2 texture coordinate at byte 8 of a 32-byte vertex
glTexCoordPointer(2, GL_FLOAT, 32, reinterpret_cast<xptr>(8));