New YveRT release back

(L) [2006/02/22] [UlfJack] [New YveRT release] Wayback!

Just to let you know. I've just let a new version of YveRT loose on [LINK http://www.yvert.de/] :


 * librified

 * better Makefile

 * shading language compiler

 * updated versions of all the java stuff.


All shaders are now compiled from Cg source code!! (Yes, I am especially proud of that.)


The kd-tree code is still borked and the compiler is unfinished. The library interface does not contain camera functions yet.
(L) [2006/02/22] [Phantom] [New YveRT release] Wayback!

Google doesn't know you... Do you have a link?
_________________
--------------------------------------------------------------

Whatever
(L) [2006/02/22] [UlfJack] [New YveRT release] Wayback!

See first post. [SMILEY Smile]

Oh yeah, and I found a better SAH for bounding box hierarchies. It gave me a ~20% boost. Might also work for kd-trees, will figure that out when my kd-tree code works again.
(L) [2006/02/22] [tbp] [New YveRT release] Wayback!

Checking...

edit: And the winner of the first-download-award is... tada... me.

edit2: As you've alluded to makefiles, you should give a look at gcc options for generating dependencies on the fly, something along the line of -Wp,-MT,$@,-MMD,$(@:.o=.d)
(L) [2006/02/22] [Phantom] [New YveRT release] Wayback!

Better SAH for BVH and kd? Tell us more. [SMILEY Smile]
_________________
--------------------------------------------------------------

Whatever
(L) [2006/02/22] [tbp] [New YveRT release] Wayback!

I can't find said compiler's sources in that release either. But i need more coffee anyway.
(L) [2006/02/23] [UlfJack] [New YveRT release] Wayback!

YveRT is four projects, three of which are java only. The raytracing library is written in C, but it can only do raytracing (no scene conversion, no acceleration structure building). You can find the shading language compiler in the slc package.
(L) [2006/02/23] [tbp] [New YveRT release] Wayback!

My bad i forgot to give other archives a look this time, maybe because i unconsciously remembered it was done in Java  [SMILEY Sad]


Jacco & i have the bad habit of naming the kd-tree builder a 'compiler', and that was what i was looking for.

Will check again.
(L) [2006/04/04] [UlfJack] [New YveRT release] Wayback!

And yet another YveRT release (we're up to 0.5 now) on [LINK http://www.yvert.de/] :


 * the kd-tree compiler now works (as described here: [LINK http://ompf.org/forum/viewtopic.php?t=35])

 * libyvert now contains an interface to specify geometry and materials at runtime (see the test application)

 * slc compiler is complete and tested

 * miniray ui has been reworked


Yay!
(L) [2006/05/18] [UlfJack] [New YveRT release] Wayback!

I've only just uploaded release 0.7 of YveRT ([LINK http://www.yvert.de/]), two days after 0.6. We havn't done much in the way of performance optimizations, but we've got a whole lot of other nice features. The short list:


 * win32 support

 * multithreaded rendering (roughly double performance for double cores)

 * epsilon-free raytracing (except the kd-tree and the torus intersection test)



The long list:


 * multithreaded rendering (yay for multicore owners)

 * extended geometry and lightsource specification

 * cleaner internal material interface

 * scissoring

 * a new imaging library (jingle)

 * refactoring of the geom package

 * changing miniray to use jingle

 * openexr format support

 * a new shading model (which we hope will improve shading performance at least twofold)

 * epsilon-free raytracing

 * more robustness for the ray-object tests

 * more shader

 * a new logo

 * Win32 support


Cheers!


-- Ulf
(L) [2006/05/19] [UlfJack] [New YveRT release] Wayback!

I havn't spend that much time on the kd-tree traversal (and there is still at least one bug in there).


You can look at the source if you like, basically, we do:
(L) [2006/05/19] [UlfJack] [New YveRT release] Wayback!

Oh yeah, we're using tiles for multi-threaded rendering. We just cut the image horizontally into stripes (10 or so). Then we have two counters, one for the next stripe number and one for the number of finished stripes. Access to the counters is synchronized, rendering needn't be synchronized, because everything happens either read-only or on the stack. When the image is done, all rendering threads go to sleep and a single thread is allowed to modify the scene, camera, etc.


It gives roughly twice the performance on my new dual-core Athlon.

back