It is currently Wed Dec 11, 2019 1:04 am


All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Rendering Multiple Materials
PostPosted: Sun Oct 28, 2012 10:45 pm 

Joined: Fri Sep 14, 2012 10:54 pm
Posts: 15
Hey there, fellow PolyVoxaliens,

I know this topic came up a lot, but i didnt find a satisfying solution yet. Splitting chunks into different meshes, one per material, looks horribly due to the materials not blending.
Sure: There is a solution. Rendering every triangle having different materials 3 Times with alpha blending enabled. I Know that. But thats pretty expensive and i a lot of work to implement.


I'm pretty new to this topic. Im glad i got my triplanar texture mapping running smoothly and even there i got quite some help by GPU Gems. :)
So maybe my idea is pretty useless since i dont have the right understanding of 3D Textures. :<


My idea is that i store the Material IDs in a (huge) 64x64x64 ( Where 64 is the resolution of the Chunk per side ) 3D Texture. As far as i read, 3D Textures are passed to the GPU as a IdentityCube.
Problem1: Can one still get the same data one wrote to the texture by using an indexing in 1/64 steps? Is the data interpolated/mipmapped/changed in any way? ( Maybe using an offset of 1/128 to prohibit rounding errors? )

Problem2: Does the GPU mipmapping on 3D Textures? If so i would have to disable that I guess. I dont know how performant 3D Textures are anyway, coming to think of that... ^^

Problem3: Not that harsh: Determining the coordinates. I guess i could simply use a similar method as i do in our lovely triplanar texturing, thats the least problem i got there.



My main problems is using the data i pass to the GPU in my shader (GLSL).

Im not very experienced with shading thats why i want to ask here first and get some pointers if and how feasible this idea is.
Warm regards and thanks in advance,

Kuro


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Rendering Multiple Materials
PostPosted: Mon Oct 29, 2012 9:46 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
I'm not sure whether you follow our blog, but there have been a few posts recently about doing smooth voxel terrain using PolyVox and the Gameplay3D engine. For example, check out the most recent post. The reason I'm working on this is (as you say) that there are problems with all the multi-material approaches I know of both in PolyVox and in other voxel engines.

The good news is that I have indeed come up with a new approach which offers a lot of flexibility compared to previous approaches. The bad news is that I don't want to talk about it too much in public as I would like to try and get a research paper out of this. So it will become public information in a few months but for now I won't go into too many details.

But if you drop me an email I don't mind outlining the basic approach I'm taking and you can see if it is of interest to you. It's quite complex though, and relies on some changes I made locally to PolyVox which are not yet available in Git.

Ok, back to your approach now.

My first question would be to ask what are the benefits of storing the materials IDs in a 3D texture rather than storing them as vertex properties. I don't think it solves the issue of interpolation between materials? But on to your questions:

KuroSei wrote:
Problem1: Can one still get the same data one wrote to the texture by using an indexing in 1/64 steps? Is the data interpolated/mipmapped/changed in any way? ( Maybe using an offset of 1/128 to prohibit rounding errors? )


Yes, the texture coordinates are all on the range 0.0 - 1.0 (same as with 2D textures). Mipmapping and interpolation are possible but optional so it's up to you whether you want to use them. You should check the OpenGL docs regarding the offset but you may need to do something here. Googling for 'openGL half texel offset' might throw up some useful results.

KuroSei wrote:
Problem2: Does the GPU mipmapping on 3D Textures? If so i would have to disable that I guess. I dont know how performant 3D Textures are anyway, coming to think of that... ^^


Yes, you can optionally perform mipmapping. As with interpolation it doesn't really make sense with material IDs...

KuroSei wrote:
Problem3: Not that harsh: Determining the coordinates. I guess i could simply use a similar method as i do in our lovely triplanar texturing, thats the least problem i got there.


I guess you can just use the world-space position of the fragment, scaled down by a fator of 64?

You might also investigate how texture splatting work for conventional heightmapped terrain, and consider whether this conept can be extended using 3D textures.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Rendering Multiple Materials
PostPosted: Mon Oct 29, 2012 1:35 pm 

Joined: Fri Sep 14, 2012 10:54 pm
Posts: 15
David Williams wrote:
I'm not sure whether you follow our blog, but there have been a few posts recently about doing smooth voxel terrain using PolyVox and the Gameplay3D engine. For example, check out the most recent post. The reason I'm working on this is (as you say) that there are problems with all the multi-material approaches I know of both in PolyVox and in other voxel engines.

The good news is that I have indeed come up with a new approach which offers a lot of flexibility compared to previous approaches. The bad news is that I don't want to talk about it too much in public as I would like to try and get a research paper out of this. So it will become public information in a few months but for now I won't go into too many details.

Neat. :) That looks promising, idd.
I overflew some articles of the blog but i didnt rly shove deep i have to admit... I will totally read that paper when it comes out. ( Hopefully soon. :) )


David Williams wrote:
But if you drop me an email I don't mind outlining the basic approach I'm taking and you can see if it is of interest to you. It's quite complex though, and relies on some changes I made locally to PolyVox which are not yet available in Git.

I would be interested in your approach but if i had to make a guess i would say you use something like runtime created texture splatting.
I thought about unwrapping the mesh and using a 2D projection ( UV-Unwrap ) with a splatting attempt, myself. Its even more efficient: No unwrapping needed. "Simply" assigning UV coordiantes to the different cases...
But there are... A LOT of cases per Material. The cases grow exponentially. Its ridiculous. oô
The naive approaches grows with x^x^x where x is the number of materials possible.

There we can use some of the knowledge we got from the marching cubes algorithm: We exploit rotations and mirroring.
I unfortunately didnt get the bitmask thingy there, but it looks pretty much promising. I will totally look into this one... Oh dear lord, why do you keep sending me ideas over my knowledge? :(
( Well, at least you send me David, bud, so i guess its something like divine justness... XD )


David Williams wrote:
Ok, back to your approach now.

My first question would be to ask what are the benefits of storing the materials IDs in a 3D texture rather than storing them as vertex properties. I don't think it solves the issue of interpolation between materials? But on to your questions:

I thought about it, but i didnt want to recompile the whole engine, since the engine i use doesnt support custom Vertex layouts. Its pretty restricted in that area...


David Williams wrote:
Yes, the texture coordinates are all on the range 0.0 - 1.0 (same as with 2D textures). Mipmapping and interpolation are possible but optional so it's up to you whether you want to use them. You should check the OpenGL docs regarding the offset but you may need to do something here. Googling for 'openGL half texel offset' might throw up some useful results.

Thats what i meant with the offset. :) It was a shot into the blue, but it seems to be at least half correct. :D

David Williams wrote:
Yes, you can optionally perform mipmapping. As with interpolation it doesn't really make sense with material IDs...

Thats quite correct... I dont even know why it was a problem for me... Maybe i was worried about the performance impact of disabling mipmapping.


David Williams wrote:
I guess you can just use the world-space position of the fragment, scaled down by a fator of 64?

Yep, i would do it like that.


David Williams wrote:
You might also investigate how texture splatting work for conventional heightmapped terrain, and consider whether this conept can be extended using 3D textures.


Thats why i think i know what your paper will be about. :P
I implemented simple texture splatting as a little shader exercise some time ago, when i was about to learn GLSL.
See above for my thoughts about this topic... I guess this may work. I dont know how fast the unwrapping is and wether i can find a satisfying method to create and use a lookuptable, but as said above: I wanted to get the hang of the mechanics of marching cube anyway, so i guess i will find some valuable hints when i dig deeper into this topic.


Thanks a lot so far, David, i really appreciate it. :)




Initial thoughts of me and a friend on the problem... we narrowed it down quite a bit so far.
Image
Uploaded with ImageShack.us


On the left is a encoded material table. Every color symbolizes one material. In theory it works. But.. look below...


Edit:
I just noticed that i can dump that idea, too, since it needs the vertices to be NOT shared.
I will recompile the engine with a custom Vertex layout, i guess. Oh gosh, that fucks me off right now...


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Rendering Multiple Materials
PostPosted: Tue Oct 30, 2012 9:48 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
KuroSei wrote:
...but if i had to make a guess i would say you use something like runtime created texture splatting.

Not really, but I just sent you a PM with a very brief overview of my approach.

That aside, I do think that the use of 3D texture splatting has some potential. If I was to persue this I might not store any material information in the volume or in the vertices. The volume would jut be to define the shape using the density field. I would then have a 3D texture at a lower resolution than the volume, and I'd give it multiple colour channels (RGBA). I'd use each colour channel to represent the strength of a particular material, and I'd sample this 3D texture from my shader and use it to control the blending. Editing materials could then be done without touching the volume data or vertices.

I haven't actually tried it so I don't know how well it would work, but it's something to think about

KuroSei wrote:
I thought about unwrapping the mesh and using a 2D projection ( UV-Unwrap ) with a splatting attempt...

I don't have any experience with unwrapping but I think it might be slow. Also, you need to make it 'stable' somehow, so that modifying one part of the terrain does not affect other parts of the terrain.

KuroSei wrote:
I thought about it, but i didnt want to recompile the whole engine, since the engine i use doesnt support custom Vertex layouts. Its pretty restricted in that area...

Sounds painful! :-(


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Rendering Multiple Materials
PostPosted: Tue Oct 30, 2012 1:09 pm 

Joined: Fri Sep 14, 2012 10:54 pm
Posts: 15
David Williams wrote:
Not really, but I just sent you a PM with a very brief overview of my approach.


And you got reply. :)


David Williams wrote:
That aside, I do think that the use of 3D texture splatting has some potential. If I was to persue this I might not store any material information in the volume or in the vertices. The volume would jut be to define the shape using the density field. I would then have a 3D texture at a lower resolution than the volume, and I'd give it multiple colour channels (RGBA). I'd use each colour channel to represent the strength of a particular material, and I'd sample this 3D texture from my shader and use it to control the blending. Editing materials could then be done without touching the volume data or vertices.

Sounds neat. Specially that one can change materials without touching the actual volume. But if you got a game where you could mine materials for example this approach would be bad, wouldnt it? The materials the palyer receive at digging have to be queried from the 3D Texture then. I Dont know how accurate that is... But meh, i lack experience with those beasts called 3D Tex.


David Williams wrote:
I don't have any experience with unwrapping but I think it might be slow. Also, you need to make it 'stable' somehow, so that modifying one part of the terrain does not affect other parts of the terrain.

I think its pretty slow, too. I didnt do any benchmarkign though. Only thinking about the implications gave me the chills.
My theoretical attempt was to iterate over every triangle of a chunk, calculating blendweights from the material IDs of the vertices and the vertices connected to those vertices. After that i would blend the material textures according to those blendweights.
To make it stable i would use an approach similar to triplanar texture mapping: Calculating texturecoordinates from world coordinates.
But for iso surfaces the texture sizes would grow into oblivion, i guess. And the blending process would be pretty time consuming. I guess the approach is fine for precompiled, static terrain though.


David Williams wrote:
Sounds painful! :-(


you bet. :D It is pretty annoying.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Rendering Multiple Materials
PostPosted: Wed Oct 31, 2012 9:03 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
KuroSei wrote:
Sounds neat. Specially that one can change materials without touching the actual volume. But if you got a game where you could mine materials for example this approach would be bad, wouldnt it? The materials the palyer receive at digging have to be queried from the 3D Texture then.

Yeah, I didn't think about that. You'd have to keep a copy of the material volume on the CPU I guess. If it's at a lower resolution then maybe it doesn't take up too much space... for example 1/4 the resolution would be 1/64 of the number of voxels compard to the main volume. But maybe it's not such a good approach for this scenario.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 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