It is currently Sat Aug 22, 2020 1:44 pm


All times are UTC




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Tue Apr 10, 2012 2:44 am 

Joined: Mon Apr 09, 2012 10:24 pm
Posts: 7
[SOLVED, see final posts]

Dear PolyVox forums (in particular David and ker),

First I'd like to thank you all for your contributions towards the PolyVox engine. Having tackled the basic examples of PolyVox and Ogre integration, I have come across a roadblock when utilizing ker's example on Triplanar Texturing Using glsl (found here: http://www.volumesoffun.com/polyvox/documentation/dokuwiki/glsl_ogre_for_triplanar_texturing_and_multiple_textures).

While the example is thorough and easy to follow, my attempts to implement the section of code responsible for fixing triangles where multiple materials appear gives me the following access violation:

Unhandled exception at 0x00841ab7 in OgreTest.exe: 0xC0000005: Access violation reading location 0x1e27cef4.

Below is the constructor for the material/alpha vector and the rendering function (based on ker's example), which uses a mesh extracted from a volume region using the smooth surface extractor. Initially, when I setup the MaterialAlpha constructor verbatim to ker's, I ran into several build errors when using the struct elsewhere.

ma.material = {1, 2, 3}

1) ma.material Error: expression must be a modifiable lvalue

2) { Error: expected an expression


Once I was able to get it sorted out with my work-around, I ran into the access violation. Below is the code I am using.

Code:
struct MaterialAlpha
{
   float material[3];
   float alpha[3];
};                                                                   
                                                                     
                                                                     
                                             
void Render::updateRegionRender(string nodeName, PolyVox::SurfaceMesh<PolyVox::PositionMaterialNormal> mesh, int x, int y, int z)
{
   std::vector<PolyVox::PositionMaterialNormal>& vertices = mesh.m_vecVertices;
   std::vector<uint32_t>& indices = mesh.m_vecTriangleIndices;
   Ogre::SceneNode* ogreNode = mSceneMgr->getRootSceneNode()->createChildSceneNode(nodeName, Ogre::Vector3(x, y, z));
   
   // Create Manual Ogre Object
   Ogre::ManualObject* ogreMesh;
   ogreMesh = mSceneMgr->createManualObject(nodeName);
   ogreMesh->setDynamic(true);

   // MaterialAlpha
   assert(indices.size() % 3 == 0);

   // find all triangles that contain more than 1 texture and create new vertices for them.
   std::vector<MaterialAlpha> vertex_extra_data(vertices.size());
   for(uint32_t i = 0; i < indices.size(); i+=3) {
      uint32_t& i0 = indices.at(i);
      uint32_t& i1 = indices.at(i+1);
      uint32_t& i2 = indices.at(i+2);
      const PolyVox::PositionMaterialNormal& vertex0 = vertices.at(i0);
      const PolyVox::PositionMaterialNormal& vertex1 = vertices.at(i1);
      const PolyVox::PositionMaterialNormal& vertex2 = vertices.at(i2);

      MaterialAlpha ma;
      ma.material[0] = vertex0.getMaterial();
      ma.material[1] = vertex1.getMaterial();
      ma.material[2] = vertex2.getMaterial();
      if(vertex0.getMaterial() != vertex1.getMaterial()) {
         if(vertex0.getMaterial() != vertex2.getMaterial()) {
            ma.alpha[0] = 1.0;
            ma.alpha[1] = 0.0;
            ma.alpha[2] = 0.0;
            vertex_extra_data.push_back(ma);
            i0 = vertices.size();
            vertices.push_back(vertex0);

            ma.alpha[0] = 0.0;
            ma.alpha[1] = 1.0;
            ma.alpha[2] = 0.0;
            vertex_extra_data.push_back(ma);
            i1 = vertices.size();
            vertices.push_back(vertex1);

            ma.alpha[0] = 0.0;
            ma.alpha[1] = 0.0;
            ma.alpha[2] = 1.0;
            vertex_extra_data.push_back(ma);
            i2 = vertices.size();
            vertices.push_back(vertex2);
         } else {
            // vertex 0 and 2 have the same material
            ma.alpha[0] = 0.5;
            ma.alpha[1] = 0.0;
            ma.alpha[2] = 0.5;
            vertex_extra_data.push_back(ma);
            i0 = vertices.size();
            vertices.push_back(vertex0);

            ma.alpha[0] = 0.0;
            ma.alpha[1] = 1.0;
            ma.alpha[2] = 0.0;
            vertex_extra_data.push_back(ma);
            i1 = vertices.size();
            vertices.push_back(vertex1);

            ma.alpha[0] = 0.5;
            ma.alpha[1] = 0.0;
            ma.alpha[2] = 0.5;
            vertex_extra_data.push_back(ma);
            i2 = vertices.size();
            vertices.push_back(vertex2);
         }
      } else {
         if(vertex0.getMaterial() != vertex2.getMaterial()) {
            // vertex 0 and 1 have same material
            ma.alpha[0] = 0.5;
            ma.alpha[1] = 0.5;
            ma.alpha[2] = 0.0;
            vertex_extra_data.push_back(ma);
            i0 = vertices.size();
            vertices.push_back(vertex0);

            ma.alpha[0] = 0.5;
            ma.alpha[1] = 0.5;
            ma.alpha[2] = 0.0;
            vertex_extra_data.push_back(ma);
            i1 = vertices.size();
            vertices.push_back(vertex1);

            ma.alpha[0] = 0.0;
            ma.alpha[1] = 0.0;
            ma.alpha[2] = 1.0;
            vertex_extra_data.push_back(ma);
            i2 = vertices.size();
            vertices.push_back(vertex2);
         } else {
            // all are equal
            ma.alpha[0] = 1.0/3.0;
            ma.alpha[1] = 1.0/3.0;
            ma.alpha[2] = 1.0/3.0;
            vertex_extra_data[i0] = ma;
            vertex_extra_data[i1] = ma;
            vertex_extra_data[i2] = ma;
         }

      }
   }

   // Begin writing to Manual Object
   ogreMesh->begin("ApeTexture", Ogre::RenderOperation::OT_TRIANGLE_LIST);
   
   // prepare the buffers
   ogreMesh->estimateVertexCount(vertices.size());
   ogreMesh->estimateIndexCount(indices.size());
   for(uint32_t i = 0; i < vertices.size(); i++) {
      const PolyVox::PositionMaterialNormal& vertex = vertices.at(i);
      const MaterialAlpha& ma = vertex_extra_data.at(i);
      PolyVox::Vector3DFloat vertex_pos = vertex.getPosition() + static_cast<PolyVox::Vector3DFloat>(mesh.m_Region.getLowerCorner()); // add chunk pos
      ogreMesh->position(vertex_pos.getX(), vertex_pos.getY(), vertex_pos.getZ());
      ogreMesh->normal(vertex.getNormal().getX(), vertex.getNormal().getY(), vertex.getNormal().getZ());
      float x = vertex_pos.getX();
      float y = vertex_pos.getY();
      float z = vertex_pos.getZ();
      const float faktor = 50;
      for(int j = 0; j < 3; j++) {
         ogreMesh->textureCoord(x/faktor, y/faktor, z/faktor, ma.alpha[j]);
      }
      ogreMesh->textureCoord(ma.material[0], ma.material[1], ma.material[2]);
   }
   for(uint32_t i = 0; i < indices.size(); i++) {
      const uint32_t& index = indices.at(i);
      ogreMesh->index(index);
   }

   // end writing
   ogreMesh->end();
   ogreNode->attachObject(ogreMesh);
}


The error appears at the pushback call located in the last correction section (where vertex0.getMaterial = vertex1.getMaterial != vertex2.getMaterial):

vertex_extra_data.push_back(ma);

This error occurs both in release and debug mode and is triggered part way through the run. At this point, the vertex_extra_data vector has a size of 25722 and a capacity of 38580. As the debugger shows, the assertion error comes from the vector.h standard header when pushing back a "non-element".

Code:
{   // push back a non-element
         if (this->_Mylast == this->_Myend)
            _Reserve(1);
         _Orphan_range(this->_Mylast, this->_Mylast);
         _Cons_val(this->_Alval,
            this->_Mylast,
            _Val);
         ++this->_Mylast;
         }
      }


Thank you for any and all assistance you may render. If there is any more information needed for clarification, just let me know.


Last edited by Eskari on Tue Apr 17, 2012 11:32 am, edited 1 time in total.

Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Tue Apr 10, 2012 9:08 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Hmmm... I'm not sure I have a good answer to this. Here's some things to think about:

1) It appears your problem has nothing to do with Ogre. But perhaps you can comment out the code which creates and later fills the Ogre ManualObject, just to be sure. Does it still crash?

2) If you look in the debugger at the value of 'ma' which is being passed to push_back() does it appear valid?

3) We should get more information anout this exception. Can you use a try/catch block to handle it and print out the error? Or perhaps you can go to 'Debug -> Exceptions' (before running the program) and tick all the 'Thrown' boxes. This should make the application break when the exception is actually thrown which might give more insight intothe problem.

4) This logic seems wrong to me (from wiki)?

Code:
if(vertex0.getMaterial() != vertex1.getMaterial()) {
      if(vertex0.getMaterial() != vertex2.getMaterial()) {
         // all 3 vertices have different materials
         ....


It checks that Material0 is different from Material1, and that Material 0 is different from Material2, but Material1 and Material2 could actually be the same? Maybe I'm missing something? I don't think this will actually cause a crash though.

5) The code can perhaps be simplified by splitting all triangles just for testing purposes. I.e. set the first two 'if' conditions to true. does it work? Does this tell us anything? Alternatively, you could force it to take the 'all are equal' path in every case. The rendering will be wrong but does it still crash?

6) You specify '...a size of 25722 and a capacity of 38580.' Are these values consistant between multiple runs?

Beyond that... well cut down the code until you have the simplest possible example that recreates the crash. Hopefully at some point it becomes clear what is happening.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Wed Apr 11, 2012 2:01 am 

Joined: Mon Apr 09, 2012 10:24 pm
Posts: 7
Thank you four your quick response David. With a little more debugging, I have narrowed down the problem to the calls to set the ma.alpha[]s - possibly relating to the problems I mentioned about not being able to use the syntax found in ker's example ma.material = {1, 2, 3}. Anyway, to address some of the questions you posed...

1) I tried commenting out the ManualObject code, and still received the errors

2) This problem occurs at the same index across multiple runs. The values of ma right before the exception appear fine and are as follows:

ma {material=0x001eeec8 alpha=0x001eeed4 } MaterialAlpha
material 0x001eeec8 float [3]
[0] 1.0000000 float
[1] 1.0000000 float
[2] 0.00000000 float
alpha 0x001eeed4 float [3]
[0] 0.50000000 float
[1] 0.50000000 float
[2] 0.00000000 float

3) When we tried to surround the pushback with a try/catch, the access violation is thrown first. However, this is the full information of the access violation as it comes up in memcopy.asm, and shows that the pointer for the pushback to the vertex_extra_data does not exist. I think this is because something went wrong with the assignment to ma. This is the value of the source and destination objects, which I think are is an invalid instance of the alphas array inside the ma:

- dst 0x1be1e17c "ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ" unsigned char *
205 'Í' unsigned char
- src 0x1bb4b0ac <Bad Ptr> unsigned char *
CXX0030: Error: expression cannot be evaluated
count 12 unsigned long

4) I agree, this does seem strange, however I also agree that I'm not sure that it would cause the crash... I will have to look into the logic more after solving whatever problem it is that I'm having

5) When forcing the triangle material correction to only use the all equal scenario, the program executes just fine (But with the obvious artifacts).

6) Yes, these values are constant between multiple runs. However, before implementing this code, my volume was being displayed properly, leading me to think that there isn't any sort of invalid data in the volume (which is what I'm assuming you were thinking with this)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Wed Apr 11, 2012 9:11 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
First of all can I just check if you are using threads at all? Just because it can be an extra complication.

Eskari wrote:
Thank you four your quick response David. With a little more debugging, I have narrowed down the problem to the calls to set the ma.alpha[]s - possibly relating to the problems I mentioned about not being able to use the syntax found in ker's example ma.material = {1, 2, 3}. Anyway, to address some of the questions you posed...


Ok, so what if you don't initialise the values at all? Obviously you won't get a usable result but it should still be ok to add the uninitialised MaterialAlphas to an std::vector. Does it still crash? Or what if you add a constructor to MaterialAlpha so that the members all get initialised to zero?

Basically we need to keep cutting parts out of your code until it doesn't crash. For example, perhaps we can simplfy it as far as this (untested code but to give you the idea):

Code:
for(uint32_t i = 0; i < indices.size(); i+=3) {
   uint32_t& i0 = indices.at(i);
   uint32_t& i1 = indices.at(i+1);
   uint32_t& i2 = indices.at(i+2);
   const PolyVox::PositionMaterialNormal& vertex0 = vertices.at(i0);
   const PolyVox::PositionMaterialNormal& vertex1 = vertices.at(i1);
   const PolyVox::PositionMaterialNormal& vertex2 = vertices.at(i2);

   MaterialAlpha ma;

   vertex_extra_data.push_back(ma);
   i0 = vertices.size();
   vertices.push_back(vertex0);

   vertex_extra_data.push_back(ma);
   i1 = vertices.size();
   vertices.push_back(vertex1);

   vertex_extra_data.push_back(ma);
   i2 = vertices.size();
   vertices.push_back(vertex2);
}


Does it still crash if we simplyfy this far?

Also, I suspect that the syntax in the wiki ( ma.material = {1, 2, 3} ) is C++11 which is probably why it doesn't compile for you.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Fri Apr 13, 2012 1:09 pm 

Joined: Mon Apr 09, 2012 10:24 pm
Posts: 7
Thanks again for your help David.

Following your suggestions I broke the code down further and slowly added each step in checking to see what causes my runtime issues.

Essentially every triangle is visited,

Code:
for(uint32_t i = 0; i < indices.size(); i+=3) {


1. its indices are pulled

Code:
uint32_t& i0 = indices.at(i);
uint32_t& i1 = indices.at(i+1);
uint32_t& i2 = indices.at(i+2);


2. its vertices are pulled

Code:
const PolyVox::PositionMaterialNormal& vertex0 = vertices.at(i0);
const PolyVox::PositionMaterialNormal& vertex1 = vertices.at(i1);
const PolyVox::PositionMaterialNormal& vertex2 = vertices.at(i2);


3.materials are acquired

Code:
ma.material[0] = vertex0.getMaterial();
ma.material[1] = vertex1.getMaterial();
ma.material[2] = vertex2.getMaterial();


4.alphas are set (to the same value each iteration).

Code:
ma.alpha[0] = 1.0;
ma.alpha[1] = 0.0;
ma.alpha[2] = 0.0;


5.MaterialAlpha ma is push_backed to the vertex_extra_data vector

Code:
vertex_extra_data.push_back(ma);
i0 = vertices.size();

vertex_extra_data.push_back(ma);
i1 = vertices.size();

vertex_extra_data.push_back(ma);
i2 = vertices.size();


6.the indices are set to the size of vertices (not really sure why this happens, but based on ker's example it should)

(Up to this point the code functions with no runtime errors, but when I add in the pushback to vertices vector)

5. the vertices are pushed_back to the vertices vector

Code:
vertices.push_back(vertex0);
vertices.push_back(vertex1);
vertices.push_back(vertex2);


Again I receive the error:

Unhandled exception at 0x01331527 in OgreTest.exe: 0xC0000005: Access violation reading location 0x1e5d8e94.

The debugger takes me through the callstack to vector.h and memcpy.asm

Could the code be creating bad pointers to the positions in the vertices vector in step2? How can I prevent this?

Extra notes:
I get this error regardless of initialization of ma. So this should have nothing to do with the ma.alpha or material values.
I am not using any threading.
You were right; the syntex error regarding the initialize lists is a C++11 only syntex (so no longer an issue).


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Sat Apr 14, 2012 8:53 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Ok, so it sounds like you have broken it down quite a long way, but really you have to keep on going. Surely it can't crash once you get it down to an empty loop?!

For example, next you can remove the initialisation of 'ma.material' in the same way that you removed it for ma.alpha.

Or perhaps the problem is with the input vertex data? What if you remove vertex0, vertex1, and vertex2, then create a single 'PolyVox::PositionMaterialNormal testVertex' (i.e. just a dummy vertex) and push that on to the vectors instead? Does i still crash? If not then it implies the problem is with the input vertex data.

Otherwise, perhaps the input index data is the problem? Now that you just using 'testVertex' you can remove i0, i1, and i2 and also the calls to 'i0 = vertices.size()', etc. Does this help?

If you find either the vertex or index data to be the problem maybe it helps to print out the data to see what's going on?

Also, in you first message you said:

Quote:
The error appears at the pushback call located in the last correction section (where vertex0.getMaterial = vertex1.getMaterial != vertex2.getMaterial):

vertex_extra_data.push_back(ma);


But in your most recent message you said:

Quote:
(Up to this point the code functions with no runtime errors, but when I add in the pushback to vertices vector)

5. the vertices are pushed_back to the vertices vector

Code:
vertices.push_back(vertex0);
vertices.push_back(vertex1);
vertices.push_back(vertex2);


Again I receive the error


So the error is now occuring in a different vector? Before it was 'vertex_extra_data' and now it is 'vertices'? So can you now remove any use Use of MaterialAlpha from your code and still get the crash?

Sorry I can't tell you whats wrong... I can just guide you in the right direction of breaking down your code until it becomes clear.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Sat Apr 14, 2012 3:04 pm 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
ok, i read all of this, so i think i got the picture. no clue where the crash comes from though.

to the take all equal path attempt, did you try taking the all are not equal path every time?

the following i0,i1,i2 assignments are this way because i was too lazy to keep an index counter am only adding vertices at the end of the vertex array anyway.

Code:
vertex_extra_data.push_back(ma);
i0 = vertices.size();

vertex_extra_data.push_back(ma);
i1 = vertices.size();

vertex_extra_data.push_back(ma);
i2 = vertices.size();


you need to have a vertices.push_back() after each index setting! the order of commands in my code is very important (yes this does not help readability i know).

though i cannot see how this could cause a crash :/

the following if branches are odd, i have no clue why i made them this way...
it needs a third layer of conditions i guess...
Code:
      if(vertex0.getMaterial() != vertex1.getMaterial()) {
         if(vertex0.getMaterial() != vertex2.getMaterial()) {


i'm kinda lost in trying to find the error, but as david said, it's now crashing somewhere else... are you sure you're working on initialized memory?
maybe your surfacemesh object is somewhat invalid?
i see you're passing it by value... i have no clue if that is a good idea...
could you try rendering a smaller volume to decrease vertex count? maybe somewhere there's a uint16_t limit breaking somewhere(no clue why, but everything is odd here).


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Tue Apr 17, 2012 3:12 am 

Joined: Mon Apr 09, 2012 10:24 pm
Posts: 7
Too clarify my initial error report with ma causing issues during the push back to vertex_extra_data was simply a misread of the debugger. The actual error was being caused by the push back to the vertices vector.

1. Code works when rendering one single mesh of 64x64x64, but rendering mutliple regions of a similar size, or one large mesh gives the same access violation error.

2. I understand that the indices should be reset before the vertex push_back to vertices; however, the reset value of i0, i1, and i2 are never reused and are overridden once an iteration of the for loop is complete. Shouldn't there be a link between the reset of indices i0, i1, and i2 back to vertex0, vertex1 and vertex2 before the push_back to vertices occurs? Could this then be the cause of the access violation in pushing back to vertices?

vertex_extra_data.push_back(ma);
i2 = vertices.size();
--> Link Missing?
vertices.push_back(vertex2);

Again, thank you for your help.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Tue Apr 17, 2012 8:45 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
I copied your code into one of the PolyVox example projects and was able to reproduce the issue. Actually I was just getting some graphical corruption to start with, but after cutting it down I did get the same crash as you. And it's a nasty one :-)

Near the start of the loop we obtain references to some of the vertices as follows:

Code:
const PolyVox::PositionMaterialNormal& vertex0 = vertices.at(i0);
const PolyVox::PositionMaterialNormal& vertex1 = vertices.at(i1);
const PolyVox::PositionMaterialNormal& vertex2 = vertices.at(i2);


And within the loop we sometimes add elements to the vector:

Code:
...
i0 = vertices.size();
vertices.push_back(vertex0);
...
i1 = vertices.size();
vertices.push_back(vertex1);
...
i2 = vertices.size();
vertices.push_back(vertex2);
...


The problem here is that a call to push_back() can cause the size of the vector to exceed its capacity. In this case a larger area of memory is allocated and the contents of the vector are copied accross, so that there is now space to add new elements. However, the references (vertex0, vertex1 and vertex2) are still referring to the old area of memory. This memory gets freed because the vector has moved and the references are now invalid.

The easiest solution is to not use references but instead use real variables:

Code:
const PolyVox::PositionMaterialNormal vertex0 = vertices.at(i0);
const PolyVox::PositionMaterialNormal vertex1 = vertices.at(i1);
const PolyVox::PositionMaterialNormal vertex2 = vertices.at(i2);


Give this a try and see if it works.

One more point - now that I've looked at the code more carefully I can say that it's not doing quite what I would expect. In particular, if a triangle contains three different materials then I would have expected that the triangle gets removed and three new triangles get created (one with each material). However, only one new triangle appears to get created (the size of the index buffer does not change). The wiki code may be using a different technique to me but you can read my approach in Section 3.5.2 of this article: http://books.google.com/books?id=WNfD2u ... &q&f=false

At any rate, the wiki code is still similar so hopefully you can develop it as needed.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Trouble with Triplanar Texturing of Multiple Materials
PostPosted: Tue Apr 17, 2012 8:53 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Eskari wrote:
2. I understand that the indices should be reset before the vertex push_back to vertices; however, the reset value of i0, i1, and i2 are never reused and are overridden once an iteration of the for loop is complete. Shouldn't there be a link between the reset of indices i0, i1, and i2 back to vertex0, vertex1 and vertex2 before the push_back to vertices occurs? Could this then be the cause of the access violation in pushing back to vertices?


Setting one of the indices to vertices.size() makes it point to the vertex which is about to be added. If we have 10 vertices (0 - 9) then a call to 'i0 = vertices.size();' makes i0 contain the value 10. Vertex 10 doesn't actually exist yet, but it is then created on the next line using 'vertices.push_back(vertex0);'.

It might be clearer to write:

Code:
vertices.push_back(vertex0);
i0 = vertices.size() - 1; //Set i0 to the vertex we just added


But it does the same thing.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  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