RenderBeams

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

Moderator: Moderators

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

RenderBeams

Post by rrTea »

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: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

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: 2316
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

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: 1910
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

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 814 times
User avatar
VilleK
Site Admin
Posts: 2316
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

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: 1910
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

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 817 times
User avatar
rrTea
Posts: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

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: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

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
Random example, here it's pretty visible.
Random example, here it's pretty visible.
shredded.gif (308.6 KiB) Viewed 24465 times
User avatar
Kjell
Posts: 1910
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

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: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

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: 475
Joined: Sat Feb 15, 2014 9:54 am

Post by rrTea »

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