. /../Lino Ray Tracer/ 1234567
written by Peterpaul kl h on Jan 18, 2006 10:05
Well, this is my optimization:
In linort.txt a powerfunction is performed to calculate specular highlights, this is implemented with a polynomial loop, but it can be done in logarithmic time.

here is my modification of the file linort.txt. (My modifications are marked with my name, search for "peterpaul")
cd/zips/Peterpaul kl h/linort_pp (9 Kb)

The framerate in the realtime example doesn't change, significantly, but it also doesn't when you comment all power code. This might just provide some more cycles to be spoiled on other cool effects, or improving realtime performance.
lost, not forgotten
written by Alex on Jan 19, 2006 01:03


written by Ouch on Jan 19, 2006 07:04
aw, yes! thank you Alex! that's the link to the 1.2 alpha release of linoleum for those just tuning in

I was getting worried that I would have to redo some of my programs with all the time you were takeing adding stuff

I'll have to dig into this tommow sadly, as it's 1AM and I have to work tommarow. >:-(
hello! :) felysian
written by Hello! :) on Jan 19, 2006 07:29
As long as this has been hijacked by alex... So cool! Tomorrow I'll start learning some of the interesting transparency stuff by modifying home_sweet_clock... make some of the changes that I think it should get. I forsee an on desktop calculator...
lost, not forgotten
written by Alex on Jan 19, 2006 19:00
Ok, redownload this:

cd/zips/Alex/lrt_alex (40 Kb)

there's a machine-language optimized version of "bprims.txt", by the name of "bprims86.txt", which makes the whole scene render 150% faster than the other.

More details later, I'm late for dinner
written by Ouch on Jan 19, 2006 20:06
Alex said:
Ok, redownload this:

cd/zips/Alex/lrt_alex (40 Kb)

there's a machine-language optimized version of "bprims.txt", by the name of "bprims86.txt", which makes the whole scene render 150% faster than the other.

More details later, I'm late for dinner
Cheater! lol j/k...
lost, not forgotten
written by Alex on Jan 19, 2006 22:47
oh, and thank you Peterpaul for that hint.
We should have frumpled in your math libraries before.

Also I should learn from you, how to work in teams: mark changes, make everything as clear as possible to the others. While for now I've been rather obscuring stuff.

And I think I should now explain why I chosen to go to machine language: the reason is simply that, while on integer operations, writing Linoleum code is not much different from writing directly in assembly, on floating-point operations things are completely different.

Optimizations are mostly aimed at taking advantage of the FPU stack to reduce the number of memory accesses. The FPU stack works in practice like an extra 8 registers, although they behave like a stack, and most operations must be performed on the elements that are on top of that stack.

On the question of portability: well, in any cases I'd like everyone to bring the regular version of "bprims.txt", along with the x86 optimized version.

By the way, here's my latest version of it, but I still need to include Peterpaul's changes - the link is the same:

cd/zips/Alex/lrt_alex (40 Kb)

the use of 6 times more memory for supersampling of edges was exaggerated... 3 times is sufficient, so I went from storing each vector holding the direction of the ray of a given pixel (as calculated from the first loop) to re-calculating it in the second loop, but only if supersampling is deemed necessary for a given pixel.

...as long as I'm here, what about code styling? (don't laugh... it's unstructured but it's still possible to make the code clearer) my main concerns are for indentation (4 chars are no tab, what about 8 chars?) and letters case (do we need to keep the capitalization of most symbol names?) of course if Ponche prefers to keep the code the way he wrote it, because he feels more comfortable this way, I wouldn't mind. I don't really want to "hijack" the project: it's Ponche's project, I'm only trying to contribute something to it, and personally curious about the possibility of having a raytracer working in real-time, at least to render simple scenes...
absent more than alex
written by Shadowlord on Jan 20, 2006 00:07
if you use actual tab characters, then everyone's editor can display them as whatever size they prefer. (Assuming they're using a decent editor)

What do you think about the possibility of supporting MMX and SSE stuff? It's all asm anyhow, so it shouldn't be too hard to support. That would give you another way to do multiple floating point operations simultaneously, faster than just doing them normally. (Though whether you can get any benefit out of it depends on the algorithm you're using, your data structures, etc - but lino practically requires use of vectors/arrays of primitive types, and that's what SSE and MMX are good on)
lost, not forgotten
written by Alex on Jan 20, 2006 00:42
Hmmm. I've looked a bit into MMX, but it seems it only maps its extra registers (which are holding integers) onto only 64-bit parts of the FPU registers. For what I understand of MMX, it will help doing very particular tasks such as streaming audio and video, but it doesn't in any way look enough general purpose to help with this program. But I may be wrong: more specifically, maybe you read something explaining how it's supposed to speed up f-p calculations?

Oh, and here's a commented version of my archive:

cd/zips/Alex/linort_alex (41 Kb)

explaining which parts I changed, and why, in "linort.txt". Well, apart from "bprims.txt", which was entirely changed anyway...
written by Cryoburner on Jan 20, 2006 01:33
I agree that actual tab characters would be better. I'm sure you noticed that I replaced all the indentation spaces in the original example file with tabs when I was cleaning it up for the realtime demo. I also selected most of the text and used a tool in my editor to swap it all to lowercase letters. I just find it a little easier to read that way.
lost, not forgotten
written by Alex on Jan 20, 2006 12:34
Right, but I'd still like to know what Ponche would think of a general restyling... it's still his project, unless we fork it and claim that one's the Ponche original raytracer, made to be a plain raytracer, and the other is a realtime version of it?
deep into the jungle
written by Ponche on Jan 20, 2006 17:45
Well, that will be ok Alex. I have no time now to think about this project so you can separate the Realtime version if you want. I agree
lost, not forgotten
written by Alex on Jan 21, 2006 02:56
Ok, next time someone has to post something about the real-time version of the raytracer, please start a new thread to do so. I would do it myself but at the moment I have nothing to add. it's rather important because, at least for what concerns me, the next things I will try to do to the raytracer code will probably be useless for a "static" raytracer, so I don't want to "pollute" Ponche's original, which code is still rather clear, specially if I keep myself away from it and go play in another place

And again thanks, Ponche, for inspiring this wonderful proggy
deep into the jungle
written by Ponche on Jun 15, 2006 14:49

Here is LinoRT 1.12, after being coding all morning, and getting the inspiration just last night. I saw a complex form in a book formed by just spheres, and from 12 to 3pm more or less i thought about how i could be able to generate one for my raytracer.

So i did, and it's nice, i think. This new version, apart from correcting some minor bugs from the main lib, also includes this new "library" for generating this nice recursive shape, which i maintain the name they wrote on the book: SphereFlake.

I'm currently rendering one shot, at 600x600 resolution with everything switched on (shadows, reflections, and supersampling), and having about 820 spheres.

And it's taking some time, what tells me that probably i should implement something like space particioning optimization, to reduce object-ray intersections or something else, in order to speed up thing a little. And also, the RealTime version of the raytracer could use it, i think. So i'll post the screenshot as soon as i have it!!!

Here is the new package
cd/zips/Ponche/lrt112 (20 Kb)

EDIT: Screenshot! 2.84 hours to render. Woaa!

└> last changed by Ponche on June 15, 2006 at 17:12
hello! :) felysian
written by Hello! :) on Jun 15, 2006 17:19
Wow! Pretty.
/me gets ready to run after the his current compilation finishes.

Rendering it right now.
- Using the platform-independant version of bprims, I was getting ~10s per line*.
- Using Alex's 386 specific version of bprims I get ~4s per line*.
1.2GHz Pentium M

* This measurement is from about 100 lines from the top, not the middle of the render.
└> last changed by Hello! :) on June 15, 2006 at 18:00
reading this thread
no members are reading this thread
. /../Lino Ray Tracer/ 1234567
42010, 14 queries, 0.104 s.this frame is part of the AnyNowhere network