Jump to content

  • Log In with Google      Sign In   
  • Create Account


Buzzy

Member Since 30 Jan 2000
Offline Last Active Feb 16 2014 11:38 PM
-----

#4953137 Don't start yet another voxel project

Posted by Buzzy on 26 June 2012 - 03:25 PM

So a while ago I saw a video for a 4D puzzle game (Miegakure). I thought it was really neat, but it got me thinking... What would an actual 4D renderer look like? What's the best way to represent the fourth dimension? I thought about using 4D tetrahedral models, rendered with a shader to select the current 3D "slice", but that seemed too unwieldy. The most straight forward way, in my mind, was to take the "ray-casting 3D voxels" concept and just add a fourth dimension.

My program uses a 4D sparse voxel octree (I call it a hypertree) which acts exactly the way you'd expect: each dimension splits into two, which means that a node has up to 16 four dimension children volumes. I copied the ray casting algorithm from the Laine and Karras SVO paper (minus the contours), and added in an extra dimension to everything. To visualize the fourth dimension (W), I leave Z as up and down, but rotate the viewer's other three dimensions so that W replaces X or Y. Mathematically it works quite nicely, and doesn't look too bad.

One of the biggest issues that I had with it is that a 4D hypertree can get very big very quickly. Since every node can have 16 children, if I were to store all the leaf nodes I'd only be able to work with relatively shallow trees (e.g. at 4 bytes per node, seven levels is 1 GB). Since it's a sparse tree I don't store all this, but the potential is there. I also came up with two other solutions to this size problem. The first is to have portal nodes, which store a transformation matrix to teleport viewing rays, or object positions, from that node to some other node (and orientation). So even if the entire world is only 128 leaf nodes on a side, you can make larger environments by hijacking other (unused) dimensions seamlessly. The portal transformation does incur a performance hit though for every ray-portal intersection.

My second solution to the size problem is to not store unique geometry at the bottom of the tree. Using a palette of premade leaf node "tiles", you can give the environment more detail without having to store it all uniquely. Or at least that's how it would work... I haven't actually implemented this yet. I got the idea from watching that Unlimited Detail video, which looks like it uses a similar idea with 3D tiles nodes.

My other issue with a 4D renderer is that generating interesting content is difficult to do without an editor. I stopped working on it about the time I realized that I'd need to make an editor to get the full potential out of it as a concept. I'll probably pick it up again one of these days though.

So that's my experience with "voxels". If anyone wants me to go into more detail about anything I can, but I don't want to post the program right now.


#4924794 Spherical Harmonics comparison

Posted by Buzzy on 23 March 2012 - 07:25 PM

You could take the difference between the coefficients of the two, then integrate over the sphere with these new coefficients, but using the absolute value of the function, to get the L1 distance. To integrate I'd say probably just do a basic Monte Carlo integration by having a set of a few dozen or so points on the unit sphere that you can plug into the resulting difference SH function. This should work because the L1 distance between two functions is something like



where and



Here, c and d are your coefficients, and the y's are the SH basis functions. So a Monte Carlo integration would be something like



for a set of N points (uniformly distributed) on the unit sphere. Here w(x) is a weight function, which would be equal to 4pi if you use a uniform distribution on the sphere.

You could also replace taking the absolute value with an L2 norm to get the L2 distance. I think I got all that right... hope that helps.

--Buzzy


PARTNERS