It is currently Sun Nov 17, 2019 12:28 pm


All times are UTC




Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: Transvoxel Algorithm
PostPosted: Mon Mar 26, 2012 9:02 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Ok, it sounds like we have a plan. We'll try to get a PolyVox release out in the next month or two, and then we'll start to integrate the TVA stuff.

realazthat wrote:
I can try and make more generic versions of things, and add in some missing stl-style typedefs (value_type is something I wish PolyVox had more of for example). However this would probably be breaking, so you would have to review, copy what you like, perhaps on a "version" change.


Indeed, the current requirement to specify both a VolumeType and a VoxelType when creating an extractor is rather ugly and probably unecessesary. Exposing the VoxelType through the volume (similar to how value_type works) should be straightforward but requires changes to all the extractors/algorithms/examples. It's worth doing though so I'll try to squeeze it into the next release as well.

realazthat wrote:
Try doing this with enums:
Code:
...

Doing that with enums drove me absolutely nuts :).


I see your point, but we just haven't had a need for code like that in the existing extractors. Keep the cube/face/edge stuff in TVA for now, but we can always pull it across in the future.

realazthat wrote:
I do have additional features I want to implement, such as skinny-triangle-elimination, geomorphing, and other features in the paper, and also provide some good base shaders for the demos as a starting point for others.


I'm curious, are you developing this TVA with a particular application in mind? Do you have a game or something you are working on?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Tue Mar 27, 2012 11:53 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
David Williams wrote:
realazthat wrote:
https://github.com/realazthat/polyvox-tva/wiki


I'll have to come back to that as I've written enough for this post. In general it looks good (particualrly the material stuff) and I think parts of it can be moved/copied to the PolyVox Wiki.


Ok, I've been back and had another look at your Wiki material. In general I think that the 'Materials and shading' section is the most relevent to PolyVox and contains some excellent links. It should all work with the marching cubes extractor as well as with TVA, so your welcome to move it to the PolyVox Wiki as and when you feel like it.

The other sections are a litle more TVA specfic, but you could already create a TVA section on our Wiki and bring them across if you like.I think you're in the best position to decide what is useful to end users here. Be sure to add a note that it's work in progress though, and maybe include a link to this topic.

Just some notes on the material and shading stuff then. Firstly the solid texture synthesis research is indeed very cool. I had a look at Johannes Kopf's work a while ago and it looks very promising, but the algorithm was quite complex and I didn't find any ready to use software. If it works as well as they claim then it's really very impressive. The survey paper also looks very interesting.

I don't have much knowledge of sparse textures but I believe they are mostly in 2D. Does TVA allow worlds which are big enough to benefit from them? There is also a GPU gems paper called Octree Textures on the GPU which extends the concept into 3D. Might be worth including that in your list as well.

I wasn't able to follow your GPU noise link, but I'm also aware of Drop-in replacement noise() for GLSL. As I recall they avoid any dependencies on resources such as textures for lookup tables.

As for fractal reblending... well that one really impressed me. Such a simple idea but I've never heard of it before. Do you have any links or images for it?

One final note on the calculation of normals - you say that they are computed from the surrounding trianges but have you considered computing them from the volume gradient instead? This is what the marching cubes extractor does and it works very well. There's no need to worry about the edge cases, for example.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Tue Mar 27, 2012 3:03 pm 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
David Williams wrote:
I'm curious, are you developing this TVA with a particular application in mind? Do you have a game or something you are working on?


I have a game in mind, yes. However the game is more of a dream; it requires a few different "research"/experimental/not-yet-existing/possibly impossible tech to come to be (aside from TVA), so I don't expect to ever be able to finish it. Mostly, it builds on DemoA which is a top-down view-dependent octree that incrementally generates its nodes on-the-fly. This can allow for insanely huge worlds, with very far visibility. I am hoping for voxel planets, with a seamless transition from space to caves. The game idea itself is mostly an FPS on multiple planets, but with strong emphasis on other elements (something like multi-planet World War II Online, with caves). Thus, some advantages of voxels (like voxel destruction) aren't as important to me personally as the caves are. The top-down concept can be seen in these old videos (without TVA): http://www.youtube.com/watch?v=4wVx2wTDP7A, http://www.youtube.com/watch?v=FpmRKo54-yU. I now implemented TVA, and I will soon want to reimplement these "planetoids" with patches fixed.

_________________
irc://irc.freenode.net/#polyvox


Last edited by realazthat on Wed Mar 28, 2012 6:52 am, edited 2 times in total.

Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Tue Mar 27, 2012 3:37 pm 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
David Williams wrote:
I don't have much knowledge of sparse textures but I believe they are mostly in 2D. Does TVA allow worlds which are big enough to benefit from them? There is also a GPU gems paper called Octree Textures on the GPU which extends the concept into 3D. Might be worth including that in your list as well.

Yes they are 2D, the idea here would be to have 3 of them and use triplanar projection. So 2D texturing techniques can be reused for 3D terrain.

As for TVA being capable of larger worlds, the top-down LOD generation approach I described in the previous post allows for Very Large Worlds, but texturing them becomes very problematic. Thus, *some* sort of runtime-procedural textures are needed, or some sort of texture paging and thus my discussion of texture synthesis of different sorts.

I've seen the GPU gems article before, it is nice, and might have some applicable ideas, but I don't think it solves the problem of scalable (large) textures, but rather is a way of breaking down a non-flat (hard to texture) surface into many tiny flat pieces so it can be textured. Thus I didn't think it would be helpful for this particular problem.

Quote:
I wasn't able to follow your GPU noise link, ...

Which link? Is there a broken link?

Quote:
... but I'm also aware of Drop-in replacement noise() for GLSL. As I recall they avoid any dependencies on resources such as textures for lookup tables.

Thanks, I added this link to the wiki page.

Quote:
As for fractal reblending... well that one really impressed me. Such a simple idea but I've never heard of it before. Do you have any links or images for it?

The idea is actually my own. It is similar to Macro Textures idea, which I thought of myself as well, but saw it around on the net too. Instead of having a macro and micro texture, you can just use the same texture. It usually removes the repetitive features if you scale them right, because you will always be looking at a scale of 1.

The reason I named it "Fractal Reblending" is because it is a similar idea to "octaves of noise" (like in libnoise) where you blend in the same noise at a different scale to add detail. Macro/Micro textures is probably superior if you find two textures that blend well. Basically this "Fractal Reblending" thing is more of a hack :P out of laziness, to use one texture. Since I thought of it myself, I don't really have any links, nor could I find any (and if you do, I'd be very interested in reading them).

As for images, I am trying to video my upgraded DemoB (traditional TVA as per the paper demo), which now has the capability to be modified. It looks like chocolate icecream (yum). Anyway, I'll be sure to zoom in and out to show you the reblending. For me, its actually hard to notice unless you look carefully, but there are probably people with an eye for these things, so it might be jarring. I'd love to get feedback on this technique after I post the video :).

Though, I am in need of a good 512^2 seamless dark rock texture, since the one I am using is ... unlicensed. This is why my shader code is languishing, and why the demos are basically unshaded at all now. I realized a while ago that I have been working hard on geometry, but the real trick to making things look good is the shading (and it does look good :)). For DemoB, I also ported it to Google Native Client, which allows one to use it directly in the browser (chrome). There are a few "bumps" like getting the shaders working (not yet), and I can't stand the wireframe mode that Ogre emulates (or at least I think it does) for gles2. It is very different than wireframe mode in GL, and makes the mesh very hard to understand (thus it is harder to appreciate it, and TVA). I am thus hesitant to release DemoB over NaCl, except as a playground/sandbox so I'll probably wait until that aspect to mature.

All these nice upgrades are not yet committed, as I am still working out a subtle bug or two.

Quote:
One final note on the calculation of normals - you say that they are computed from the surrounding trianges but have you considered computing them from the volume gradient instead? This is what the marching cubes extractor does and it works very well. There's no need to worry about the edge cases, for example.


Yes you are right about that; I merely implemented them as the paper says to avoid trouble (and there was lots of trouble :)), since I never did voxels before, and had no idea how to generate normals. I did see you do something with gradients in your code. I also did try to abstract normal generation to the traits (very simply), so it might even be possible to change the one-liner there to something that calculates normals differently. Originally I wanted to generate normals via Policies (stl/boost idea), so perhaps one day this can be done (sure to have caveats though).

_________________
irc://irc.freenode.net/#polyvox


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Tue Mar 27, 2012 4:05 pm 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
One more thing about Micro/Macro/Reblending. It might even be possible to reblend for ever as you get closer so you always see an image at an average scale of 1 (using some extra math). The Graph Blending idea generalizes this to arbitrary graphs of images, which can have loops. So Micro/Macro/Reblending is just a tiny subset of a full graph.

_________________
irc://irc.freenode.net/#polyvox


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Wed Mar 28, 2012 6:29 am 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
DemoB, now with the ability to perturb voxels (sphere brush).

I've made a video of DemoB as it is now. I demonstrate the some problems, some nice things, the "Fractal Reblending" trick, and generally have fun. Read the description and annotations for technical details.
See video here:
http://www.youtube.com/watch?v=dEJtR_uy4zs

If you try to run the demo yourself, you will need to put a rock.png texture into SRC/media/materials/textures/., because the one I use is actually ripped off an HD minecraft texture pack. Surprisingly, I can't find any usable public domain or freely licensed minecraft texture pack, nor do I have any general public domain rock texture. If you want to look at the shader, its in SRC/media/materials/programs/triplanarmaterial.cg.

More fun with an interesting side effect of scaling:
http://www.youtube.com/watch?v=Qpm6HVqEBX4

_________________
irc://irc.freenode.net/#polyvox


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Wed Mar 28, 2012 11:06 pm 

Joined: Fri Feb 18, 2011 8:41 pm
Posts: 173
Oh wow, is it really coming then? Transvoxel in PolyVox in a few months? This would sure give me a reason to go back to old designs I had :)

Good luck!


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Thu Mar 29, 2012 9:05 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
realazthat wrote:
Which link? Is there a broken link?


Actually it's working now... perhaps the site was just down temporaily.

realazthat wrote:
The idea is actually my own. It is similar to Macro Textures idea, which I thought of myself as well, but saw it around on the net too. Instead of having a macro and micro texture, you can just use the same texture. It usually removes the repetitive features if you scale them right, because you will always be looking at a scale of 1.


Well, it's a nice idea :-)

realazthat wrote:
Though, I am in need of a good 512^2 seamless dark rock texture, since the one I am using is ... unlicensed.


I've often got textures from the FilterForge library in the past. Some of them look a little artificial as they are procedually generated but other look quite nice, and they all come with bump/normal/specular maps.

realazthat wrote:
I've made a video of DemoB as it is now. I demonstrate the some problems, some nice things, the "Fractal Reblending" trick, and generally have fun. Read the description and annotations for technical details.
See video here:
http://www.youtube.com/watch?v=dEJtR_uy4zs


Very nice! I did see the blending occuring at the time you were demonstrating it, but I didn't notice it te rest of the time (and I assume it was still occuring). So I think it is a pretty good effect.

Shanee wrote:
Oh wow, is it really coming then? Transvoxel in PolyVox in a few months? This would sure give me a reason to go back to old designs I had :)


Yep, hopefully we'll start integrating after Voxeliens is out the door.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Fri Jul 20, 2012 9:40 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
I thought is about time I checked to see what the current status is here. Obviously we're running a bit behind in terms of getting the PolyVox release out, but if you've been following the forums/Git then you'll have seen that activity is starting to pick up. Are you still working on the TVA stuff and/or the game you were building?

I wanted to make sure that you have seen a couple of recent posts which could have an effect on your work. Firstly, we've started talking about the way we can restructure Git in order to keep it more stable and more easily allow contributions from other developers. Secondly, we've made some changes to the way voxels work in order to increase seperation between the voxel types and the algorithms which operate on them.

Let us know if you have any thoughts on these.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Sun Jul 22, 2012 3:04 pm 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
David Williams wrote:
I thought is about time I checked to see what the current status is here. Obviously we're running a bit behind in terms of getting the PolyVox release out, but if you've been following the forums/Git then you'll have seen that activity is starting to pick up. Are you still working on the TVA stuff and/or the game you were building?

I wanted to make sure that you have seen a couple of recent posts which could have an effect on your work. Firstly, we've started talking about the way we can restructure Git in order to keep it more stable and more easily allow contributions from other developers. Secondly, we've made some changes to the way voxels work in order to increase seperation between the voxel types and the algorithms which operate on them.

Let us know if you have any thoughts on these.


I'll take a look at that page about git. I'll also adapt the use of polyvox voxels. Just tell me what revision is considered stable, or perhaps I should wait until git is restructured, to begin.

_________________
irc://irc.freenode.net/#polyvox


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net