. /../Lino Ray Tracer/ 1234567
deep into the jungle
written by Ponche on Jan 16, 2006 15:08
I had exactly the same problem this morning, don't know why. Winzip 10.0 seems to uncompress it right. I'm uploading it again. Tell me if there is any problem.

cd/zips/Ponche/lrt11 (14 Kb)

EDIT: PP is faster than me, evidently.
i haz title: speed-g-dof
written by Speeder on Jan 16, 2006 15:42
I saw some photos of your raytracer, and Lino is fast, I think that he can support raytracing my image...

Why raytrace each colour in separate: Each colour behave in a different way, this is what generates the rainbow, some colours refract in different ways than other, so, they will keep changing the direction, and hitting different points and doing different shadows, this is why a Diamond is beutyfull, the normal glass, do not show much difference of refraction values in each colour, but the diamond do this, is visible how the light decompose, and make each facet be lighted in one colour, so some facets became purple,. and others yellow, instead of all facets being the same colour, this method, OBVIOUS only works in Images with transparent things... And they will make the transparent things MUCH MORE realistic if you can understand me

Example: A white ray hit a sphere... The blue ray will defract a little, the red ray a little more, and the green ray much more (this is a example...) if you put various white cubes near this sphere, instead of all then become white, you will see each one in a different colour
unreal engine 3.0
written by Crembo on Jan 16, 2006 22:22
The technique you refer to is impossible in normal ray tracing. You see, the "pure" idea of raytracing is to take a lightsource, shoot rays off it (hence raytracing) and if any of them hit the camera surface then record that as a color.

However, doing that would mean that the simplest render would take years to complete on the super-est of supercomputers. So what is done today is backwards raytracing. In other words, you shoot rays from the CAMERA and record them if they hit a light source.

Thus is light defraction impossible.

However, a relatively recent technique has been invented called "Photon mapping" that DOES do some controlled forward raytracing using specific variables, lights and objects in a scene...

But that's best left for huge projects like POV-Ray, neh?

Edit: Fixed some awe-inspiring, horrifying typos.
lost, not forgotten
written by Alex on Jan 17, 2006 00:26
It works, from Peterpaul's ZIP!
I really wonder why... however, thank you very much!

Now, let's experiment...

edit:
*downloads Ponche's remaked ZIP*

edit II:
yes, works from Ponche's one as well, now

edit III:
perhaps an unsupported compression method, more advanced than most unzippers, and only recently introduced
lost, not forgotten
written by Alex on Jan 17, 2006 11:17
er... there's a wonderful set of three-divisions-by-the-same-value in bprims.txt ("sphere normal"), but I suppose nobody thought of optimizing the code a little, so far? I'd store the inverse of the radius as an extra data entry in a sphere primitive, and then multiply the triplet B,C,D by that...
written by Cryoburner on Jan 17, 2006 12:33
I've updated the realtime demo a bit, adding mouse-controlled movement and a framerate display. I also cut out a couple of the light sources to improve performance, and altered the materials a bit for aesthetics. The left button moves the camera forward while the right moves it back. You can also rotate the view in any direction you wish by using the mouse. Press any key to exit.

cd/zips/Cryoburner/linort realtime 02 (19 Kb)

The scene itself hasn't changed much, but I'll make something a little more interesting for the next release, and add some movement to the objects while I'm at it.
deep into the jungle
written by Ponche on Jan 17, 2006 12:33
Ok, here's LinoRT version 1.11, but don't expect Adimensional MultiLight Mapping From Interspatial Lithium Eaters feature... I've just put it under LGPL and made a little optimization by Alex suggestion.

cd/zips/Ponche/lrt111 (15 Kb)
written by Cryoburner on Jan 17, 2006 12:59
Since Ponche posted his slightly altered version only a couple seconds after my post, I already needed to update the source file a little to compile with the new version. : P Apparently, an attribute was added, so the inverse of each sphere's radius is currently included in each object's definition.

As far as performance goes, it seems to be about the same as before, although there could potentially be a performance improvement at very computationally intensive times.
deep into the jungle
written by Ponche on Jan 17, 2006 14:59
More optimizations are needed of course. When i've got time...
lost, not forgotten
written by Alex on Jan 17, 2006 21:29
Meh... I don't know which changes were made in the new version of the core, but here's my version of the realtime one. What I did was basically optimizing "bprims", leaving all the rest almost intact. There was a bug in version 1.1 that prevented the background color to show properly when no primitives were hit, because it jumped to "apply primitive color" anyway. Hmm...

cd/zips/Alex/linort realtime 03 (37 Kb)

About the "bprims" found in there: compiling Cryo's "02" scenery with that, and no doublesize screen, it boosted rendering from 19 to 28 fps on this computer.

Hints on f-p optimizations:
as you see in bprims, the sign of an F-P value is the most significant bit, or 80000000h, always. If that bit is zero, the value is positive. If that bit is 1, the value is negative. Checks against zero can be speeded up by making integer bitmask checks rather than real floating-point checks. Also, complementing the sign bit is way faster than using ++-- when you want speed in place of code readability.

But most important: working with registers doesn't make F-P operations faster, it makes them slower instead! The FPU in Intel processors is designed to work with memory operands only (no registers): although Linoleum provides the syntax for using registers, using registers compells it to pass the registers onto stack memory before performing the operation.
lost, not forgotten
written by Alex on Jan 18, 2006 02:24
Sorry, double post.
Insonnia made me do this:

cd/zips/Alex/lrt_alex (40 Kb)

This does 3x3 supersampling at interactive frame rate (of about 10 fps on my Athlon 2800), and with a resolution of 320x240 pixels. 2 planes and 5 spheres.

This was achieved by optimizing "linort" so that it supersamples only on edges, not on uniformly coloured areas or on areas showing little variations of color. In practice, it supersamples only where it might be needed, depending on a value, [raytracer supersampling eta], which represents the minimum difference (between any of the RGB components of adjacent points to the left and to the right of the currently rendered point) which triggers supersampling.

For optimizations, though (to avoid re-calculating what's already done), the raytraced needs an "rgb buffer" of 6 times the area of the display. Then, the output buffer is what holds the final scene.

hmmm... this thing got really interesting
I didn't think it would have been fast enough, not even on my PC.
mukyu
written by Explorer on Jan 18, 2006 02:27
this is getting really cool...!
written by Micmacreturns on Jan 18, 2006 02:52
That is just plain awesome!
kamikazemadman
written by Peterpaul kl h on Jan 18, 2006 07:34
And while optimizing the code Alex also managed to make it completely useless for all, since he used instructions which will only be introduced by his yet to be released new version of Linoleum...

Well, let's try to implement my simple idea for optimization in the old raytracer then.
written by Cryoburner on Jan 18, 2006 09:44
Heh, I noticed that too. Ah well. : P

I didn't bother trying to fix the optimized raytracer library to work with the older compiler, since I figure we *should* have the new compiler available soon. I did make the couple tiny changes necessary to make the 'LinoRT Realtime 03' demo compile with the un-optimized library though, so that I could get an idea of the increase in performance. From the starting camera position, the framerate was 8 fps, while it was 13 fps with the optimized raytracer. That's certainly a nice improvment. : )

I didn't convert the supersampled realtime demo, but I imagine it would be something less than realtime with the older raytracer library. Namely, we'd have to render an image 9 times its size for similar antialiasing, and that would likely drop performance below 1 fps on even today's fastest home computers. Anyway, it's looking nice, and I'll try some more things with it once I actually regain the ability to compile it. : D
reading this thread
no members are reading this thread
. /../Lino Ray Tracer/ 1234567
40300, 12 queries, 0.079 s.this frame is part of the AnyNowhere network