2 replies to this topic

[rouncer]

So, you can use a sparse voxel octree to save ram in a volumetric representation of 3d data (only storing the fact its either inside or outside the model for nodes that terminate off the surface of the model) therefore saving ram, and still having enough data to know the matter/space takeup exactly.

this is really nice.

the only problem is, to create a sparse voxel octree texture thats readable by gpu you can only create it on cpu!!! it takes a recursive algorythm and thats beyond shaders for sure.

Id like to be able to convert to and from a 3d array for boolean edits - so a volumetric description is necessary, but like I said, a point list of the surface plus a normal maybe you could flood fill in from the surface, but then catch 22 - theres no way to perform a flood fill on gpu too.

so even if i did have these sparse voxel octree textures representing my world chunks, id get really quick conversion to brute volume yes... but id still be stuck doing really slowpoke work on the cpu to create them (and recreate them after edits) so its a bit of a waste of time using them and i might as well use a point list of the surface instead.

Only problem with the point list is its not capable of producing a volume(without flood filling on cpu with normal data)... what im really asking here is, is it at all possible to create a svo texture on gpu, and if it isnt, what alternatives do i have for representing a volume in less ram than actually storing a 3d array.


why all this gpu madness? cause id like the tools to be gpu accellerated, working with volumes is a complete waste of time cpu side, theres just not enough power, and i dont have a 256 core machine, except my gpu...

Also, since I have to drag video memory back across the bus to save it to disk (the world is streamed off disk) then I cant use brute volumes (even though that would be a huge waste of disk space) cause they wouldnt send through the bus quick enough anyway.

help please... can you think of a way to store a voxel surface primarily thatll convert to volumetric data and back again?

[rouncer]

hey i just figured it out, using the point list, to calculate a volume from it, as long as it has normals.

what you do is do it mip by mip, and develop a pointerless octree from it - and you use that to make the brute volume.

so you compare the first mip to the second mip, you can see you can see what nodes actually terminate here, and on these you compute the volume by checking the normals of the first mip voxels... then you do it mip by mip, eventually collectively youll have the volumetric data of the whole thing in a pack of mips you should be able to convert to a single brute volume array.

on gpu and everything, i bet reedbeta could have told me this, he explained a mip by mip gpu approach to me before - sorry if my post was a little backwards written, english is not my specialty. hehe

ok, thanks guys.

[rouncer]

all i basicly worked out is no, you can do a flood fill 2d or 3d in the gpu. cool!