XFRT - LGPL implementation of OpenRT

(L) [2006/11/23] [Royce3] [XFRT - LGPL implementation of OpenRT] Wayback!

I'd now like to informally announce the engine I've been working on, as I think it's in a state that would be interesting to fellow rtrt engine writers. It's still alpha, but thanks to this forum and all the papers, articles and tutorials online it's coming together rapidly.

This engine is, with Wald's permission, an lgpl implementation of the OpenRT api.

It's home page isn't much to look at because I'm still making rapid progress with the engine:

[LINK http://xfrt.sourceforge.net/]

Features:

-OpenRT compatible
-Instancing
-BIH structure
-havran-based bih traversal
-programmable shaders ( OpenRTS compatible )
-rtut-clone utilizes glut/opengl for cross-platform windowing

Accomplishments:

-found cheap solution to numerical inaccuracy caused by translating ray into object space.

Coming Soon:

-There's a couple small things lacking that could speed up the rendering more: BIH constructor currently doesn't generate empty nodes. Also going to experiment with not normalizing primary rays.
-Nearly-automatic clustering ( run a client on another PC - set password - source engine queries network for clients to use ). My hope is this feature will put realtime performance in the hands of all game developers to help make rtrt a reality sooner.
-I'm holding off on any SIMD coding ( other than my early experimentation ) until I'm sure I have all the other algorithms done well.

Help Needed:

-I'm not a Linux user/developer. There are a couple small things that would be needed to make the code *nix-compatible.
-SIMD expert

(L) [2006/11/23] [Phantom] [XFRT - LGPL implementation of OpenRT] Wayback!

Nice one. About your remark about not normalizing primaries: I've been playing with this in my head also and I believe Reshetov experimented with that also... I'm not sure if it's possible though, not with anything but minimal shading. I need a normalized vector for Phong anyway...

(L) [2006/11/23] [craouette] [XFRT - LGPL implementation of OpenRT] Wayback!

I've done it, not normilized rays.
its is working for me, a bit quicker, but had a few drawbacks:
- fix epsilon on intersection are useless (for example, a shadow ray has the light for origin and the shaded point - origin as direction).
- primary rays need to be normilzed for shading or even to compute the reflection direction, but this can be done in steps (like computing the length, doing somethiung else, dividing by hte lenth, doing something else).

(L) [2006/11/23] [Royce3] [XFRT - LGPL implementation of OpenRT] Wayback!

>> craouette wrote:I've done it, not normilized rays.
its is working for me, a bit quicker, but had a few drawbacks:
- fix epsilon on intersection are useless (for example, a shadow ray has the light for origin and the shaded point - origin as direction).
- primary rays need to be normilzed for shading or even to compute the reflection direction, but this can be done in steps (like computing the length, doing somethiung else, dividing by hte lenth, doing something else).

I commented out the primary ray normalization and it had no visible detriment to any of the tutorials and examples I have. However, I'm not doing any reflection/refraction in any of the shaders, yet.

Since not every primary ray is going to be reflected, it makes sense to defer normalization until it's actually needed.

(edit)

OTOH the OpenRT api may force me to pass a normalized vector to the shader... My nearly empty scene (only two triangles) went from 30fps to 40fps so it can make a huge difference.

(L) [2006/11/24] [goodbyte] [XFRT - LGPL implementation of OpenRT] Wayback!

You don't need normalized rays for reflection per se (as long as your shading-normals are normalized), but you do need them for almost all shading types (I am unaware of any shading models where you don't need them), however by defering normalization you can at least skip nozmalization for rays that misses the scene completly.

I havn't seen any large speed decrease from normalization, maybe you should test if you can get away with just _mm_rsqrt_ps(x) when calculating the vector length (iirc rsqrt_ps takes ~3cc, whereas sqrt_ps takes ~50cc), and you can always add a newton step after rsqrt if you need the accuracy.

(L) [2006/11/25] [tbp] [XFRT - LGPL implementation of OpenRT] Wayback!

sqrtps takes 39 cycles on a k8, rsqrtps is best described as a RNG and getting a NR refined rsqrtps to cover the same domain as the original spoils most of the fun.

Now that's for shading, so random bits don't matter much as long as you know where and when they happen.

(L) [2006/11/26] [Royce3] [XFRT - LGPL implementation of OpenRT] Wayback!

>> tbp wrote:Oh and while we're talking about an OpenRT clone, [LINK http://ompf.org/forum/profile.php?mode=viewprofile&u=128 bouliiii] may have something to say; [LINK http://bat710.univ-lyon1.fr/~bsegovia]

Very cool! I had heard of his engine but didn't realize it was an OpenRT clone. However, when I went to his website I discovered it was GPL, so I guess I'll just keep working on my engine.

XFRT - LGPL implementation of OpenRT back

Board: Board index ‹ Ray tracing ‹ Tools, demos & sources