pouët.net

a forest gump, so that i can run in it. (sorry)

I did manage to get mod repetition with more complex objects working pretty much glitch free, so it is possible :)

A forest.. difficult I think, it'll look a little strange with no overlapping trees, no? Still, could be cool with varied rotation, scale and colour (and a nice non-uniform repeat).

One thing I tried with the repeat function was using something like mod(p, sin(p)). With some more complex function in there you can get semi-random repeats, but it then becomes a real bitch to ensure your geometry stays inside the tile.

Then again, for a forest.. trees look OK distorted in most cases. Why not use a plain mod(p, 1.) and then distort p.xz to get the same effect?

Normally you would have the grid more spare with a bit more random offset inside each box, and then overlay a couple of grids to get it dense and overlapping..

There's some idea, yes.. :) i don't like to evaluate say 4 neighbours all the time, it's going to be a framerate killer... :/

I've been playing arround with an approach that is a bit different too than a traditional volume texture to store the signed distance function to the surface of the object. It's using a lot less memory, though it has drawbacks. But if i want to scale to get ~100 assets in the video memory i'm forced to go this way. It's not based on a tree-style hierarchy.

Ow, poor bunnies :3

Not, unlimited detail! Unlimited bunnies!

http://www.pouet.net/prod.php?which=57526

Las's spikeball code! Your famous! xD

They didn't steal it ;)
But I'm really sorry for the ugly green material which looks like crap - due to a lack of temp registers we were not able to fit the proper material in time.

It's nothing special yet, but I sort of invented unlimited cube rendering!
Joking aside, it allows for some interesting things.

Everyone loves cubes, right?

a13X_B : looks exactly like the stuff i did today :)
playing around with "meta-cubes" :P

why do metacubes in a raymarcher when they can be done much more effectively with rasterization?

bcs it's hip

Lord Graga: because you are wrong ;)

las: really? but well... depends on the effect that you wanna achieve... I guess.

marching cubes is so 1990's. Also the resolution is doomed to be bad, else the triangle count explodes quickly.. But what about doing it in perspective space then.

But in that case you just have to scale your cube in a VS with a texture lookup or a direct evaluation and voila..

nystep: Actually, marching cubes in raymarchers are less resolution dependant I think? Maybe it will ultimately lead to more steps for each ray to hit the target surface because of nitty-gritty textures, but it shouldn't be that bad. And now I just contradicted my previous statement saying that rasterization is (always, implicitly) more effective.

dependent*

nystep: maybe you "just have to scale your cube in a VS" (did that in flight666 at least), but that's an awful lot of degenerate geometry (which still has to pass the tri-setup bottleneck in the gpu) in the open areas and a similar amount of overdraw in the filled..

it looks too me like that he is using marching squares, because there are only 2 dimensions in that "cube-space" though :D i.e the image shows not cubes arrange on z-axis. if he however use marching cubes, why don't we see cubes filling up the whole grid?

a13X_B: Already done on Amiiigah!!!

rasterisation is not always more effective, one thing that is often forgotten is that rasterisation is a O(n) process on primitives. As a result, despite all you can do with LOD and popping models with a lower resolution at a distance, you'll always have trouble matching the scalability of raytracing techniques, on large environments.

there's always a point, in the number of triangles/primitives, where you'll find out that ray-(marching/tracing) will get faster. So which algorithm is more effective depends on the amount of geometry that you have to handle. That's also one of the reasons why i think ray-(marching/tracing) will win in the future, because we won't always want to design games that take place in small valleys with only 10 trees arround. ;) But the challenge on the side of ray-(marching/tracing) is still animation. wait and see.

@Lord Graga, i think we don't talk about the same resolution here :) i was refering to the grid resolution of the marching cubes algorithm.

Any by the way people, the screenshot a13X_B posted has nothing to with marching cubes or marching squares or even marching duck.3ds... It's modulating the size of a cube by some ISO-surface.

It's been done shit-loads of times before, with the example I just gave as by no means the first example. The first I can think of is Aura for Laura, but I'm sure someone will correct me with an earlier version ;)

That isn't to say that it isn't a cool effect, I'm even guilty of making at least one version of that effect (but least I added something new, namely accurate AO). I can imagine that it'd be cool in a ray-marcher as long as you get the sensation of an infinite field, and the edges clean (a13X_B did neither). But I do expect aliasing to become a big problem for such a case in any ray-tracing approach.

and "In raymarching, there is no grid..." :)

nystep: It's not like you can't do something clever (like using interval arithmetic to early-cull empty areas of your ISO-function) on an effect like this with rasterization. And in general cases, rasterization isn't any more O(n) on primitives than ray-tracing is; you need to build an acceleration structure for both to get rid of that. In fact, ray-tracers are worse in the naive case, because you need to process each primitive for each pixel, so you get O(nm) rather than O(n+m) that naive rasterizers are.

Surely the key thing with ray marching is what you can do with a distance function like this. It's not merely a mesh you could texture + light, you can have it interacting with lots of other functions to make something new. Try rasterising this blending into a mandelcube or something smoothly in 3d ;)