swordlegend / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

Assumign non-indexed triangle list in RecastRasterization::rcRasterizeTriangles #17

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. There is no reproduction of the issue as I'm just reviewing the code.
-----------------------------
Expected:
The three vertices passed into RecastRasterization:rasterizeTri would be 
gathered using the index buffer and not assuming a triangle list.
-----------------------------
Result:
RecastRasterization::rcRasterizeTriangles
LN 297-299 seems that the assumption that vertex buffer is a triangle list. 
Where v0, v1, and v2 all mark only one vertex (a starting vertex) 
supporting that they are
referencing a triangle list and not an indexed triangle list, which to the 
best of my knowledge is the formate in which the data is stored.

RecastRasterization::rasterizeTri
ln 226-228 also supports my conclusion, as we are copy a vertex worth of 
data over to the array "in".

In Sample_StatMeshTiled
Ln 715 The original vertex buffer is passed in which is intilized as an 
indexed triangle list.  But in this case it is not used as such. 

-----------------------------
What version of the product are you using? On what operating system?
SVN revision 65 - Windows XP 64bit

-----------------------------
Please provide any additional information below.
There is a large chance that I'm simply mis understanding the system as 
these step seems like an integral part of creating the spans.  I will do 
some testing with creating some tmp arrays to hold the vertex data and pass 
that in.

Original issue reported on code.google.com by shawnlha...@gmail.com on 12 Nov 2009 at 7:46

GoogleCodeExporter commented 9 years ago
As an addendum changing rcRasterizeTriangles to use what I believe are the 
correct 
vertices doesn't seem to effect the outcome of the generation process. 

Original comment by shawnlha...@gmail.com on 12 Nov 2009 at 8:01

GoogleCodeExporter commented 9 years ago
Go ahead and strike this defect.  Just realized I was thinking about how the 
buffers 
are used incorrectly.  On second look everything correct, sorry about that.

Original comment by shawnlha...@gmail.com on 12 Nov 2009 at 9:41

GoogleCodeExporter commented 9 years ago

Original comment by memono...@gmail.com on 15 Nov 2009 at 10:01