ZGameEditor forum

Hi guys,

Attached is a simple example of which the Bitmap can be swapped out in FL Studio.

As a sidenote, not a big fan of how this is currently handled in FL Studio though. Would have preferred that Bitmap properties could be defined in a similar fashion as the current float-based rotary knobs. That way you could also prevent people from messing up your preset with random bitmaps

K

Thanks Kjell - that is pretty cool. One thing that surprised me is how much of a difference using the display list made too.

with display list = 58.8 FPS
without = 29 FPS

I'm definitely going to start using display lists myself.

Here is with RGB depth - so this can be made in to the PixelParticle preset.


performance improvement is unbelievable -

CPU version runs ~ 6 FPS
GPUversion 58.8 FPS

Hmm,

The 58.8fps is suspiciously close to 60fps .. big chance the application / your video card driver is simply capping the framerate, in which case it could go way beyond that. I'm getting over 1300fps on my system ( no, that's not a typo ).

Did you set FrameRateStyle to free? And what refresh rate is your monitor set to?

K

I'm getting over 1300fps on my system ( no, that's not a typo ).

Thats amazing -

probably is capped , not set to free - using the frame rate monitor on the visualizer in FL Studio.

Edit : monitor refresh rate is 60.

Important to note - video export fails (just black screen) when you use an openGL display list - A performance hit without it - but still very fast. Not sure what is going on there - but I has to replace the call list with the code block to get my video export to render.


Anyway - this worked very well with a 30 FPS video texture too:

http://www.youtube.com/watch?v=54B2X4waRB8

That is awesome guys

Can't look into it now (I'm kinda busy during the week) but will asap.

You think it's possible to implement my physics code into that and it's gona run a quadrillion times faster?

Hi, looks like you guys are making some progress here

I'll have to follow this from a distance at the moment because I'm very busy but regarding the display lists failing on export it is because the OpenGL context needs to be recreated when there is a new surface such as video export or window/detached and this leaves the display lists that was created invalid.

The ZGE render components deal with this automatically and recreate their OpenGL-state when needed but when scripts call OpenGL functions directly we need another solution. I'll probably just change it so that OnLoaded is called again when surface is recreated. I'll make a note of that for now.

You think it's possible to implement my physics code into that and it's gona run a quadrillion times faster?

Yes - I'm sure of it - and way beyond. Kjell did an excellent job on the basic shader for this.

You should be able to figure it out from there - I can't wrap my head around your physics code. I'm looking forward to seeing a GPU version of your preset.

To put it in perspective:

Currently,

your preset 64x64 with lots of arrays and calculations is running at ~ 6 FPS on the CPU

Here processing

256x256 image
capped out > 60 FPS, but still not as demanding as your script

Pushing the envelope - 16x the size of the array you were using goes beyond you performance needs. This can't even run on the CPU.

1024x1024 capped out > 60 FPS


HD Video 30 FPS --> to 256x256 x 30 images/sec

Is still going at 40-50 fps

Hi guys,

StevenM wrote:Kjell did an excellent job on the basic shader for this. You should be able to figure it out from there.

That's probably a little optimistic Since ZGE doesn't support floating-point buffers ( it actually does internally for the GPU Array, but it's not exposed anywhere in the Editor ) you need to pull some ( fixed-point ) tricks to get the data around.

StevenM wrote:Pushing the envelope - 16x the size of the array you were using goes beyond you performance needs.

You can't really compare it like that though .. look-ups are a entirely different beast.

StevenM wrote:HD Video 30 FPS --> to 256x256 x 30 images/sec is still going at 40-50 fps

In that case the video decoder probably accounts for 99% of the CPU usage .. doesn't have much to do with the preset itself

K

Kjell wrote:Hi guys,

StevenM wrote:Kjell did an excellent job on the basic shader for this. You should be able to figure it out from there.

That's probably a little optimistic Since ZGE doesn't support floating-point buffers ( it actually does internally for the GPU Array, but it's not exposed anywhere in the Editor ) you need to pull some ( fixed-point ) tricks to get the data around.
K

For my preset to work I need to store currently 14 float variables per vertex.
I used the 3rd array dimension for that.
I'd need to read each pixel's color independent of the vertex xy position too.

fixed point is OK I think as the variables have a very limited range (positions, colors, velocities, angles ...)

Could you help me out here? I'm completely lost when it comes to the shader code.

What's the VertexShaderSource and FragmentShaderSource about?

Also I'd need to access FL's data from the shader (Parameters, BandSpecArray and AudioArray)

I guess that's done through the UniformVariables node?

Also I need some functions to calculate stuff: atan2, sqrt, floor, clamp
Are these available in shader code?

You can't really compare it like that though .. look-ups are a entirely different beast.

That is what I was comparing though, current method opposed to the use of the shader - am going under the assumption that using a look up will not be necessary and a completely different approach will be implemented.

The video result has me impressed the most. I didn't think the decoder had much to do with it. - Doesn't the shader have to do a lot of work to extract the pixel data from each frame?

alphanimal wrote:Also I'd need to access FL's data from the shader (Parameters, BandSpecArray and AudioArray)

I guess that's done through the UniformVariables node?

Also I need some functions to calculate stuff: atan2, sqrt, floor, clamp
Are these available in shader code?

Yes - all you have to do is use uniform variables for parameters- check out Ville's GPU example - it contains both Audio Array and Spectral band examples.

Your math function are there:

This is a useful quick reference -

http://mew.cx/glsl_quickref.pdf

OK thanks that's useful!

How can I store float (or fixed if necessary) variables for each vertex?