Hi,
Is there a way to make all points in all primitives coplanar? It's OK if the points shift a little here and there.
Thanks!
Making all points in all primitives coplanar
4237 8 0- Ethernaut
- Member
- 24 posts
- Joined: Oct. 2014
- Offline
- BabaJ
- Member
- 2129 posts
- Joined: Sept. 2015
- Offline
- Ethernaut
- Member
- 24 posts
- Joined: Oct. 2014
- Offline
Sure thing! Here's a .bgeo file with a super low poly mesh, just bring it in with a file node.
Notice how many of the quad primitives don't have coplanar points. The final model will be used in some “1980's vector arcade” looking graphics, but when the game engine triangulates those non coplanar faces I end up getting some annoying artifacts.
Thanks!
Notice how many of the quad primitives don't have coplanar points. The final model will be used in some “1980's vector arcade” looking graphics, but when the game engine triangulates those non coplanar faces I end up getting some annoying artifacts.
Thanks!
- BabaJ
- Member
- 2129 posts
- Joined: Sept. 2015
- Offline
I've attached a file that gives some perspective on what your dealing with.
With Output A - just use a divide sop, but I am guessing this is what your game engine is doing anyways and so not what you want.
Keep in mind that with any solution if you have adjacent primitives, one being co-planar and the other not, because they share the same points on the edges where they meet, if you change one point belonging to the non co-planar primitive that happens to be also used by the other primitive; You basically fix one but make the other non co-planar.
Output B uses an algorithm that does ‘fix’ every single primitive it loops over, but because of what I just said, ends up making a mess by ‘ruining’ the previous ones it fixed. So a ‘blanket’ approach using the same algorithm isn't possible.
Output C uses a facet sop to create individual points for each primitive so the blanket approach like in B ensures that all primitives are co-planar - but you no longer have a useful topology.
Output D brings in the option to selectively go in and work on only certain primitives. With this approach you are basically manually deciding on which primitive or sets of primitives your going to work on in getting them co-planar.
This way, with some capacity for parameter adjustments on the algorithm you can eventually go through all of the primitives and get your result.
But if your going to do all that work, why not go back to the start and model in a way that doesn't produce the non co-planar primitives to begin with?
With Output A - just use a divide sop, but I am guessing this is what your game engine is doing anyways and so not what you want.
Keep in mind that with any solution if you have adjacent primitives, one being co-planar and the other not, because they share the same points on the edges where they meet, if you change one point belonging to the non co-planar primitive that happens to be also used by the other primitive; You basically fix one but make the other non co-planar.
Output B uses an algorithm that does ‘fix’ every single primitive it loops over, but because of what I just said, ends up making a mess by ‘ruining’ the previous ones it fixed. So a ‘blanket’ approach using the same algorithm isn't possible.
Output C uses a facet sop to create individual points for each primitive so the blanket approach like in B ensures that all primitives are co-planar - but you no longer have a useful topology.
Output D brings in the option to selectively go in and work on only certain primitives. With this approach you are basically manually deciding on which primitive or sets of primitives your going to work on in getting them co-planar.
This way, with some capacity for parameter adjustments on the algorithm you can eventually go through all of the primitives and get your result.
But if your going to do all that work, why not go back to the start and model in a way that doesn't produce the non co-planar primitives to begin with?
- Ethernaut
- Member
- 24 posts
- Joined: Oct. 2014
- Offline
Thanks, that was very clear and concise!
The reason I'm getting so many non coplanar prims seems to be because I'm converting voxels to polygons, Im not sure if there's a way to enforce coplanar polys when doing that.
It looks like manually selecting and fixing offending prims with method “D” will be the way to go.
Thanks!
The reason I'm getting so many non coplanar prims seems to be because I'm converting voxels to polygons, Im not sure if there's a way to enforce coplanar polys when doing that.
It looks like manually selecting and fixing offending prims with method “D” will be the way to go.
Thanks!
- BabaJ
- Member
- 2129 posts
- Joined: Sept. 2015
- Offline
- Ethernaut
- Member
- 24 posts
- Joined: Oct. 2014
- Offline
Maybe, but the goal is generating very low resolution meshes (think 1980's vector display graphics), and at that resolution it seems like some hand editing will be unavoidable. I was just hoping for a hidden Houdini trick that would allow a 100% procedural workflow. Also, I'm lazy.
Thanks for the help!
Thanks for the help!
- BabaJ
- Member
- 2129 posts
- Joined: Sept. 2015
- Offline
- divi-cig
- Member
- 7 posts
- Joined: Sept. 2014
- Offline
-
- Quick Links