Author Topic: Hyperion 1.0.2 available  (Read 2261 times)

0 Members and 1 Guest are viewing this topic.

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2357
    • oZone3D.Net
Hyperion 1.0.2 available
« on: November 22, 2005, 09:03:17 PM »
Hi everybody!

you can grab the new release of hyperion here:
http://www.ozone3d.net/repository_hyperion_win32_installer.php

In the menu : the usual bugfixes, the most important one was the particles rendering in point_sprite mode.

Keep in mind that point_sprite mode is an OpenGL extension that allows to speed up particles rendering by reducing traffic to gpu:
instead of sending 4 vertices in order to draw a textured quad per particle, point_sprite mode allows us to send one vertex per particle only.
It's the graphics card's job to re-create the billboarded textured quad (yes, in that case, the billboarding is done by the gpu).

All this to say that, following one of the last stages of particle standard codepath optimization, the point_sprite codepath
has been somewhat torpedoed. Still sorry :oops:

Now for the new features, the majority of them were added in order to realize the Static AO demo.

FBO. FBO(s) (stand for framebuffer objects) are a recent OpenGL extension that allows a simplified access (and faster in theory)
to graphics card buffers: texture color buffer and depth buffer mainly. FBO are mostly used with dynamic textures (the texture content
is dynamically modified during the execution). One of the most important applications of dynamic textures is the rendering to texture,
more known as RTT. RTT are used intensively in the oZone3D reflexion engine.

RTT standard codepath is very fast and in theory FBO should have to increase that speed. But nothing! RTT standard codepath is on average
10% faster than the FBO one. I would have preferred the contrary. I will find the gremlins sooner or later unless the problem comes from
graphics drivers. I've done some performance tests on my 7800gt / forceware 81.94. Maybe on radeons chipsets, things will work differently.
If someone wants to do some tests, that would be great!

But FBO are also interesting for their texture's dimensions which can be of any size (but always a power of 2). RTT standard codepath used in reflexions does not allow texture dimensions to be greater than the 3D window size. If a hyperion demo initializes the 3D window in 1024x768,
reflexion texture dimensions can not be greater than 1024x512. FBO codepath removes this restriction so we can have a 2048x2048 reflexion
texture with a 800x600 3D window 8)

Ambient occlusion and vertex attrib. Occlusion data (bent-vector and occlusion factor) can be loaded in the vertex attribute you want.
This choice is dependent of the GLSL shaders used in your demo.

Vertex attributes are additional data that can be bind to each vertex. These attributes are used in GLSL shaders (through the attribute keyword
in the vertex shader). For an ambient occlusion shader with with bump mapping, occlusion data must be loaded in the second vertex attrib, the first one is automatically used by the engine to store the tangent vector essential for bump mapping.

Shadow volumes. Shadow volumes are not new but the ability to use a gpu shader for ambient pass yes. To keep things simple,
the shadow volume engine operates in two passes: one ambient pass and one illumination pass.

Ambient pass allows to draw the scene lit only by the global ambient light. This is equivalent to render a scene that would be in a shadow.
Illumination pass allows to draw all non-shadowed areas, those that are lit by light sources.

Up to hyperion 1.0.0, only one shader bound to the material was used and only for illumination pass. Now, you can bind two shaders: one for the
ambient pass and one for illumination pass. This new feature was needed  for a test scene rendered in ambient occlusion
with shadow volumes as well.

The last new thing is the possibility to restrict, or more exactly to forbid the demo's execution on one of the two main platforms:  nvidia and ati. This new feature is due to their different way to behave when they execute GLSL code. Indeed, while working on the Static AO demo, I had a problem with user clipping planes that are not taken into account with nVidia gpu. The solution to this problem was to update the glsl gl_ClipVertex variable. With radeons chipsets, on the contrary, user clipping planes worked perfectly but the gl_ClipVertex update crashed the demo on my 9800pro! That's why the possibility to choose a target platform for the demo has been added to check_hardware_caps element of scene node.

Here's the presentation of the new hyperion release. Do not forget to use the forum to report all suspect behaviors of hyperion on your pc.