Is there a good way to store data per edge in a mesh for read on the GPU, or are you better off just storing that data per triangle, even though it is likely redundantly stored on the triangle that shares the edge?
-
Could you spell it out a little bit more, like how youd store and retrieve the data (like, the index where edge data lived, how you'd find it)
Drafted this up real fast to prove the point but it probably won't compile. Been in glsl land for awhile but wrote it in as best I remember hlsl, so my syntax may be off.pic.twitter.com/SKr6vkTpid
-
-
I've done a similar thing with quad-based anything. Particles and terrain are easy ones. particleId = vertexId / 6; indexInQuad = vertexId % 6; quadIdx = quads[indexInQuad]; //another LUT. Mean you can do terrain rendering with no index or vertices. Just textures.
-
The key to making this work is that the "entry" buffer (ie, the indices in the wavefront obj) are linearly ordered, where you know that all three points of a triangle are contiguous.
- Näytä vastaukset
Uusi keskustelu -
-
-
Bah. Refactoring as I was writing comments and some of those comments are wrong or misleading. Here I've touched it up some.pic.twitter.com/HIX6OjeANq
-
I noticed in the other branches of this thread you mentioned that an edge is where two triangles meet. I don't think that's a good definition of a triangle edge, because a mesh can have holes, BUT you can access adjacent triangles pretty easily this way if you set up the data.pic.twitter.com/qptnygUXx8
- Näytä vastaukset
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.