RenderBeams

Found a bug? Post information about it here so we can fix it!

Moderator: Moderators

Post Reply
User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

RenderBeams

Post by rrTea » Thu Jan 15, 2015 3:48 am

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...

Code: Select all

<?xml version="1.0" encoding="iso-8859-1" ?>
<ZApplication Name="App" Caption="ZGameEditor application" NoSound="1">
  <OnUpdate>
    <AnimatorSimple Duration="0.5" AutoStart="255" Target="Explosion.Width" AutoReverse="255" RepeatCount="10" FromValue="1" ToValue="0.01" Smooth="255"/>
    <ZExpression Comment="trace it">
      <Expression>
<![CDATA[trace
(
intToStr( Explosion.Width *100 )
);]]>
      </Expression>
    </ZExpression>
  </OnUpdate>
  <OnRender>
    <UseMaterial Material="ColorMono"/>
    <RenderBeams Name="Explosion" Count="5" Length="5" Width="0.9136"/>
  </OnRender>
  <Content>
    <Material Name="ColorMono" Comment="Default: white, shaded"/>
  </Content>
</ZApplication>
Am I doing something wrong here or?
Last edited by rrTea on Tue Mar 17, 2015 7:23 am, edited 2 times in total.

User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea » Fri Jan 16, 2015 11:01 am

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.

User avatar
VilleK
Site Admin
Posts: 1924
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Fri Jan 16, 2015 12:34 pm

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.

User avatar
Kjell
Posts: 1650
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Fri Jan 16, 2015 12:36 pm

Hi rrTea,

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.

Image

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.

K
Attachments
Beams.zgeproj
(3.26 KiB) Downloaded 89 times

User avatar
VilleK
Site Admin
Posts: 1924
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Fri Jan 16, 2015 2:34 pm

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).

User avatar
Kjell
Posts: 1650
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Fri Jan 16, 2015 2:57 pm

Hej Ville,
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.

K
Attachments
Beams.zgeproj
(3.33 KiB) Downloaded 94 times

User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea » Sun Jan 18, 2015 12:12 am

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.
Hej Ville,
Thanks!

Edit: cleanup.

User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea » Tue Mar 17, 2015 1:56 am

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?
Attachments
shredded.gif
Random example, here it's pretty visible.
shredded.gif (308.6 KiB) Viewed 2557 times

User avatar
Kjell
Posts: 1650
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Tue Mar 17, 2015 6:14 pm

Hi rrTea,
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 :wink:

K

User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea » Wed Mar 18, 2015 2:34 am

It's true that such intersections should usually be avoided but I was just after a particular effect - I'll solve it differently. Thanks!

User avatar
rrTea
Posts: 323
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea » Sat Apr 11, 2015 10:58 am

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.

Post Reply