feb 6, let me introduce you to kd-vision 2006 back
(L) [2006/02/06] [Phantom] [feb 6, let me introduce you to kd-vision 2006] Wayback!Hm yeah that's a good idea.
(L) [2006/02/06] [Ono-Sendai] [feb 6, let me introduce you to kd-vision 2006] Wayback!Looks cool, might try something similar myself at some point.
_________________
[LINK http://indigorenderer.com/]
(L) [2006/02/07] [Phantom] [feb 6, let me introduce you to kd-vision 2006] Wayback!I implemented tree visualization too but I am too lazy to take pictures.
Or rather: When I am not in the office I spend all my time coding, and then when I am in the office, I can't code, but I can't take screenshots either. [SMILEY Smile]
This is so addicting. Good to be back.
(L) [2006/02/07] [Phantom] [feb 6, let me introduce you to kd-vision 2006] Wayback!Not another kind of visualization, just the same kind of crap that you use to spot inefficiencies like you're Tank. [SMILEY Smile]
And being on the tail: It seems I have a habit of trying things first, but you always make the best implementation. I used to be lagging behind 10-15% before we freezed the projects, and now it appears to be a stupid kd-tree bug. And right now, MLRTA is only hurting, not helping, so you're still a bit ahead, especially because of that 64-bit code (you claimed a 20% speed increase). As I don't even have 64bit hardware, I won't be able to catch up with that for the moment. I will go for 4x4 packets though.
(L) [2006/02/07] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!...just login? Gah, I'm sorry. Anyway, that was me. [SMILEY Embarassed]
(L) [2006/02/07] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!I'm sorry, I didn't mean to upset you. Thing is, I'd like to get down and dirty in the code. Maybe I can convince you to give me your code? [SMILEY Wink]
(L) [2006/02/07] [Phantom] [feb 6, let me introduce you to kd-vision 2006] Wayback!He's not upset, he just gets carried away really easily. [SMILEY Smile]
(L) [2006/02/07] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!Just a couple of things that I've missed in earlier posts:
- the bbh does sort of partitions space as well, at least the way I build it
When building the bbh, I'm looking for something like a splitting plane in every direction. The only problem are long thin triangles. You can see that problem here:
[IMG #1 ]
See the bright red spot on the right? Thats a place where the triangles are long and thin and overlap each other. That means that there are large amounts of overlap between boxes, which the bbh is really bad at. What I could do is some sort of "loose" bbh. That is, a bbh where primitives are allowed to be present in more than one node, and any single node does not have to bound the entire primitive. Like so:
[primitive]
[prim][itive]
The bbh then essentially becomes a kd-tree for that part of the scene, except that it requires more storage (the whole two boxes are stored instead of just the splitting plane).
- Indoor scenes often still have large amounts of free space. A BBH can efficiently cull that free space by not enclosing it.
- Also, when you use a scene bounding box for your kd-tree, the object in free space argument isn't that important, because only rays that hit the scene bounding box are considered anyway.
- When I get out my math, your kd-node visiting code must be at least about 22/23 times faster than my bbh box visiting code, and I am really amazed at that. Maybe parts of that are due to compiler options and x86_64 goodness?
(/me goes once more to try to get 64bit debian to run on his 64bit machine)
[IMG #1]:Not scraped:
https://web.archive.org/web/20071029233618im_/http://users.conquer-space.net/~ulf/rastercar-bbh.jpg
(L) [2006/02/07] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!I'm posting this in 64-bit mode. I've recompiled Yve RT and it does not make any difference whatsoever - give or take 3ms / frame (that's about the amount it varies anyway).
(L) [2006/02/07] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!Debian unstable, just like yourself, gcc 4.0.3. I'm guessing here, but I think you can get a lot of that with the right compiler flags - well, except the additional registers of course. I'm gonna look into that tomorrow - if I have time.
(L) [2006/02/09] [UlfJack] [feb 6, let me introduce you to kd-vision 2006] Wayback!These are my compiler flags for _both_ 4.0.3 and 4.2:
-msse -ffast-math -funroll-all-loops -fsingle-precision-constant -O3 -std=c99
(and of course:)
-Wall -Wno-unused-function -g
(plus a couple of libraries - GL, glut and jpeg)
I'm really not interested in the best possible combination of compiler flags for every subsubversion of every subversion of every version of gcc - that would just be a whole waste of time.
When I profile the code, the hierarchy traversal is the largest chunk, followed by shading and primitive intersection parts. For very simple scenes, the shading cost can actually be higher than the hierarchy traversal. I'm "forcing" SSE usage for hierarchy traversal anyway, so there's not that much the compiler can do to optimize except different register allocation strategies.
Feel free to disagree with me on that. [SMILEY Razz]
I'm much _more_ interested in how you do your kd-tree traversal so radically different from what I do. (Or at least, why your machine is so much faster than mine. /me wants a new pc.)
(L) [2006/02/09] [tbp] [feb 6, let me introduce you to kd-vision 2006] Wayback!And to put an end to the compiler switches debate, even if i'm convinced that's not a good idea, here's my sequence du jour for the SSE packet traversal part.
back
![[IMG:#2]](images/1a46160ef7cb03223ab3ff49e4a83a099e0856734c7be2526caca59af9c78278.jpg)
![[IMG:#4]](images/8f274c438b9b97cc8c6700c802193496b50deac1d0e286e35653bb858a14f830.png)
![[IMG:#8]](images/8d594021d857357d42fe0528b30033e37c827d12f133e0bc2ab50946f55f71e3.jpg)
![[IMG:#10]](images/3bf800c37d915ee516956741f1cdd32e865796206bb769fb2bbab975b01d0ab7.png)
![[IMG:#2]](images/0f4633417bae7817959edd5ea327b292707b94bdb86429e7cd3ed624040cd507.png)
