pouët.net

Raymarching Beginners' Thread

category: code [glöplog]
Yes, and just to make sure you got my idea, when I talked about using the voxelized boxes (uniform or bvh, but bvh seems better) for sdf, I meant building the sdf of the box shaped grids, not defining the sdf in grids... I hope I'm making sense.
added on the 2016-06-12 18:47:57 by golem golem
I mean, this whole idea seems efficient only if we can define the sdf in continuous (vector) space.
added on the 2016-06-12 19:02:07 by golem golem
@all stop throwing around BVH as if it has any deeper meaning beyond bounding volume hierarchy, you can have sphere trees, axis aligned bounding box trees, (loose-)octrees/quadtrees, kdTrees, R-Trees and so on. Hell one could even mix and match them and encapsulate oriented boxes in axis aligned boxes encapsulated in spheres and so on. BVH does not say anything about the structure or used volume type. BVHs by no means needs to be non-uniform, octrees and their respective 2d counter part quadtrees for example are uniform and are still BVHs. The fact that they can be sparse makes them "non balanced trees" but their volumes are still uniformly sized.

@asd-romeda What do you want to voxelize boxes into ? More boxes ?
I'm terribly sorry but everything you wrote on the last 3 pages makes no sense to me at all, I'm actually wondering if you're trolling or I just dont get what you're talking about.
added on the 2016-06-12 21:45:47 by LJ LJ
Quote:
I'm actually wondering if you're trolling or I just dont get what you're talking about

Ehh, those two are hardly equivalent weights though.
added on the 2016-06-12 21:50:33 by Gargaj Gargaj
lol, I have to say one thing: I really like pouet, the only place in the grand internet, when you can get emotional about BVHs and people will understand you! :)
added on the 2016-06-12 22:36:01 by tomkh tomkh
Quote:
@asd-romeda What do you want to voxelize boxes into ? More boxes ?


Yeah, obviously LJ has a point, but since when people actually make perfect sense?
I will defend asd-romeda a bit: he probably just trying out stuff and didn't grasp the right terminology yet.
added on the 2016-06-12 22:45:56 by tomkh tomkh
haha, asdromeda == Bruce Dell !
After that Unlimited Detail-Thread was on the frontpage again he came to learn from us and educate us at the same time! ;)
the illustration Gargaj posted represents stuff traditionally referred to as quad/oct/kd-trees instead of BVHs, tho. in a kd-tree (of sorts) you divide up space, in a BVH you place objects in a hierarchy -- though you can do a splitting BVH where you can get the best of both approaches (little overlap between neighboring volumes and lesser growth of the amount of references.) splitting bvhs are the best alternative at least for triangle geometry, no idea how well stuff like this works for SDFs -- probably not so well, since the SDF kinda already gives you a somewhat optimal traversal algorithm.

well, the most elegant way imo would be to mesh the SDF and trace triangles; less iterations and exact results.
added on the 2016-06-13 00:27:01 by msqrt msqrt
LJ: you don't get what I'm talking about. I don't want to voxelize boxes, I voxelize the meshes. Just like how other people do it. The point isn't about bvh at all. No matter you voxelize the meshes into simple grids, bvh or other things, my point is beyond all these. What I'm saying is that instead of arbitrary meshes in a scene, we put boxes in place of meshes, each surrounding a mesh. Then we have a scene completely comprised of cuboids, which are easy to construct sdf for. When a ray traverses the sdf and hits one of those cuboids (rectangular cuboids, 'boxes'), we bring the bvh/kd tree/octree/whatever grid based structure of the mesh that the box belongs to, and continue to traverse the ray in the grid to find intersection.
Hardy: in case you're not trolling (tho I doubt it's the case), please be constructive. I'm just asking a question.
msqrt: well that's another idea, seems cool, or what I know... I just got an idea and thought it's never done before and could improve something in world and expressed it here, and now I have to prove people I'm not a troll or pretentious or a nazi or a serial killer or...
added on the 2016-06-13 02:11:01 by golem golem
Well speaking of which...you actually seem to be quite advanced into this. Traversing the grid to find intersection etc... Doesn't sound like a non-technical person to me.

At the same time you have wrote:
Quote:
I'm just interested in demoscene. I can't write even one line of code.


How you want to test your ideas then? ;)

Anyway - we just trolling each other here on a daily basis, that is what pouet is for most of the time :) So I don't actually mind some inconsistencies in your posts. Let's improve the world with better SDF tracing!
added on the 2016-06-13 02:33:44 by tomkh tomkh
Tomkh: word!
Also, the fact that I can't code but all I could do is to grow theorical ideas made me ask it here instead of trying it myself :)
added on the 2016-06-13 02:47:26 by golem golem
Asd-romeda: that's why most coders doesnt give a shit about your ideas :) learn to code or stick to youtube.
added on the 2016-06-13 03:07:52 by quisten quisten
By most i mean sane.
added on the 2016-06-13 03:08:17 by quisten quisten
Uhm... hypothesizing approaches without the knowledge/ability about implementation certainly does not
Quote:
improve something in world


I could prate all day long about how one could discretize arbitrary geometry to infinite levels of detail™ if I cant bring it to the table and prove my point its nothing but pipedreams.

Also using all kinds of spatial optimization structures in pretty much anything 3D rendering(and many other fields) is the norm. You need to know whats out there, why its being used and its limitations to actually start thinking about better/faster approaches.

But hey, the internet is a free place!
added on the 2016-06-13 03:25:26 by LJ LJ
that was directed @asd-romeda
added on the 2016-06-13 03:26:42 by LJ LJ
Quote:
Asd-romeda: that's why most coders doesnt give a shit about your ideas :) learn to code or stick to youtube.

That's the single most stupid shit I've ever heard.
It's not about coding skills. which coder can be successful and inventive without theorizing ideas first?
If you don't understand an idea someone posts on the Internet, you better stop yourself from commenting on it, instead of being angry that why someone who can't code behind a computer is asking a question about an idea. Not being able to code doesn't mean I don't understand computer graphics.
LJ: you could preach all you want about coding skills, world improvement, etc but as I'm 120% sure no one in this thread has understood what I'm proposing yet, unless someone actually understands the idea and then proves it's wrong, I stand firmly by my idea.

Quote:
Also using all kinds of spatial optimization structures in pretty much anything 3D rendering(and many other fields) is the norm. You need to know whats out there, why its being used and its limitations to actually start thinking about better/faster approaches

And what makes you think that I don't know how those things out there work to some reasonable extent?
added on the 2016-06-13 07:33:34 by golem golem
By reasonable extent I mean, for example I don't know about lookup speeds that much, yes, but it's not a matter of much importance in here.
added on the 2016-06-13 07:37:22 by golem golem
Quote:
I'm 120% sure no one in this thread has understood what I'm proposing yet, unless someone actually understands the idea and then proves it's wrong, I stand firmly by my idea.

Ideas are cheap

https://www.youtube.com/watch?v=DkGMY63FF3Q
added on the 2016-06-13 07:41:26 by britelite britelite
Ideas are taking the world further in every field, including computer graphics.
added on the 2016-06-13 07:56:38 by golem golem
But showing your idea in action is also more convincing than "waaah, you guys don't understand MY IDEA!!!!1"
added on the 2016-06-13 08:15:42 by britelite britelite
Not all ideas are created equal :)
added on the 2016-06-13 08:27:34 by Gargaj Gargaj
Quote:
I don't want to voxelize boxes, I voxelize the meshes. Just like how other people do it. The point isn't about bvh at all. No matter you voxelize the meshes into simple grids, bvh or other things, my point is beyond all these. What I'm saying is that instead of arbitrary meshes in a scene, we put boxes in place of meshes, each surrounding a mesh. Then we have a scene completely comprised of cuboids, which are easy to construct sdf for. When a ray traverses the sdf and hits one of those cuboids (rectangular cuboids, 'boxes'), we bring the bvh/kd tree/octree/whatever grid based structure of the mesh that the box belongs to, and continue to traverse the ray in the grid to find intersection.


Your cuboids are called bounding volumes; something that includes the whole object and is (hopefully) easier to test against. This is more or less what everyone does already, for examples see recent mercury intros.

Since the 80s, all triangle-based ray tracers have also done this, but in a smarter (for triangles, at least) way: Instead of doing an SDF of the bounding volumes, you just group the bounding volumes inside larger bounding volumes in a sensible way. You keep on doing this for the current set of larger bounding volumes until you have a root node containing your whole scene and hey presto, a bounding volume hierarchy is born. This has the definite advantage over SDFs that you don't have to iterate, "just" walk down the hierarchy and test cuboid (or sphere?) collisions -- easy and fast as heck. You definitely don't want to march an SDF if the alternative is exact and costs about as much as one step of the marching.

You can also do this top-down for implicit geometry, for example in Pheromone we do a normal sphere intersection and then if we want it to split up, just push a set of smaller objects into a local stack structure. Also works recursively and forms a nice IFS. We can fire about 8 paths of 3 bouces (tho with the post processing we had to cut this down somewhat) with next event estimation so about 50 rays per pixel at an "acceptable" frame rates in 720p.

Not sure what you mean that in the end we bring the "structure of the mesh that the box belongs to", just that we revert to the normal acceleration tricks? Because the normal acceleration tricks (BVH, octree of sorts) are better than what you suggest -- no iterative marches involved.

That all being said, I do have to admit a slight personal bias against ray marching. It feels lazy and boring unless you do really cool geometry or have really nice lighting hacks or at least design it very well. Plus, well, it's kinda slow and artefact-y even with all the tricks and hacks to make it less so.
added on the 2016-06-13 09:17:02 by msqrt msqrt
If this thread is not entertaining, I don't know what is!

asd-romeda is just thinking outside of the BVH box, give man a credit...and money.
added on the 2016-06-13 09:18:50 by tomkh tomkh
There's quite many layers of this stuff that people have already thought through, he's obviously free to do that again by himself instead of hopping on the giants' shoulders. Others won't probably find that process too deeply interesting, tho.
added on the 2016-06-13 09:28:03 by msqrt msqrt
Quote:
which coder can be successful and inventive without theorizing ideas first?

None, which is why they're coders, which means they can do both.

Ideas are worthless without the skills to put them into practice.

(Damn it, I fell for the flamebait and posted something..)
added on the 2016-06-13 10:15:08 by gloom gloom

login