pouët.net

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.

I mean, this whole idea seems efficient only if we can define the sdf in continuous (vector) space.

@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.

Ehh, those two are hardly equivalent weights though.

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! :)

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.

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.

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...

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:


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!

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 :)

Asd-romeda: that's why most coders doesnt give a shit about your ideas :) learn to code or stick to youtube.

By most i mean sane.

Uhm... hypothesizing approaches without the knowledge/ability about implementation certainly does not

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!

that was directed @asd-romeda

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.


And what makes you think that I don't know how those things out there work to some reasonable extent?

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.

Ideas are cheap

https://www.youtube.com/watch?v=DkGMY63FF3Q

Ideas are taking the world further in every field, including computer graphics.

But showing your idea in action is also more convincing than "waaah, you guys don't understand MY IDEA!!!!1"

Not all ideas are created equal :)

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.

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.

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.

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..)