Animating RenderBeams' Speed and Width doesn't produce any effect. Reading Help doesn't mention anything about these two properties being a special case or antyhing, also same thing but with Length has a visible effect so I expected that animating the rest works the same...
Number of beams is rendered incorrectly, around half of the number entered in the "Count" field. For example Count 1 = 0 Beams, Count 2 = 1 Beam, Count 3 = 2 Beams, Count 4 = 2 Beams, Count 5 = 3 Beams etc.
That it renders less than count is a bug. Thanks for noticing. It will be fixed in next update. The animating Speed and Width problem I cannot promise will be fixed.
I had a quick look at the RenderBeams source code and have to say it's bizarrely implemented. Every time you change a property value the effect is basically reset. Attached is a quick example ( for Ville ) of how i'd implement* the component ( without adding any new features ).
*Although you might want to use a separate array ( opposed to interleaving the data ) for the texture coordinates so you can move the generation of those to the array expansion statement.
The demo uses the horizontal mouse position to set the width and the vertical mouse position to set the length of the beams, while the beam count and the ( overall ) speed are animated automatically.
Just goes to show that we should add support for ZGE scripted components so that Kjell can write his own implementations
I think that my original code works like it does is because I spawn beam instances similar to how RenderParticles work and store length and width in the instances because I wanted to have some random variation (which probably could be skipped).
VilleK wrote:I think that my original code works like it does is because I spawn beam instances similar to how RenderParticles work and store length and width in the instances because I wanted to have some random variation (which probably could be skipped).
You can simply add another parameter for the 10% width variation though .. see attached.
VilleK wrote:That it renders less than count is a bug. Thanks for noticing. It will be fixed in next update. The animating Speed and Width problem I cannot promise will be fixed.
Certain camera positions can cause lots of clipping / distortion when the beams overlap. Sometimes it's barely noticeable, but it can get pretty visible especially if the beams aren't rotating fast.
I guess I should always keep the beams straightened to face the camera and disable the ZBuffer in the material used to render them, but sometimes it's not very practical or a differtent angle is needed etc. What can I do to avoid the clipping effect in such situations?
rrTea wrote:What can I do to avoid the clipping effect in such situations?
Impossible ( without using a workaround ).
The easiest workaround is probably to switch cameras temporarily. Just make sure that the distance to depth-range ratio is identical for both cameras otherwise the intersection won't occur at the same depth. Another possible workaround is to render the beams head-on or with depth testing disabled to a FBO, and use that as a texture applied to a plane. But personally i don't think that's worth the effort just to be able to have the beams and 3D text intersect .. in fact, usually you want to prevent such intersections
Kjell wrote:Attached is a quick example ( for Ville ) of how i'd implement* the component ( without adding any new features ).
Very nice!
This version of RenderBeams would be very useful for making explosions, the current component is mostly suited for various decorations as far as I can see... (Sorry to bump the topic up like this but I was just in the middle of making a generated explosion and I remembered I didn't mention such an obvious point in this thread.)
Edit: I found a very nice example of RenderBeams in action, I'll post the link here just for the record (also it's such a nice illustration). It's in one of Kirby's games: Example video
(the whole video can also be downloaded from here)
Note how the beams get thinner and longer etc when Kirby charges up.
