Floating vertices, optimization problems


#1

Hi all. I’ve been using Qubicle since 1.x and I’ve recently upgraded to version 3. I do love it.

“New users can only post one image per post”. This topic is goint to kill me… I’ll try posting one piece at a time with an image per piece and see what happens.

I’ve always needed to export my models to common file formats such as DAE, OBJ, FBX or X; I started exporting my models to DAE using Qubicle Unite even when all I needed was importing those models into Blender for rendering. That’s my preferred format above others available. Sadly, I’m used to re-modelling my objects in Blender because of optimization inconsistencies and painful mesh topology. Right now I’m working on two projects for which that workflow has proven unbearable. So, I’m here to tell you what the problem is and see if there might be a better option, hopefully from within Qubicle. I’m providing an example: a tank.

Here’s the tank itself within Qubicle 3:


#2

It’s a simplified version but it will do for this example. It’s made up by different parts, such as hull, turret, gun, tracks, individual wheels… I’ve exported it using Qubicle Unite (QEF to DAE) and the OBJ, DAE and FBX exporters. The best results are achieved with the “manifold” option but the problem is there no matter what. I always get the same result: floating vertices and bad (open/overlapping) geometry.

Let’s see one isolated side armor plate (separated from the tank) in Blender:


#3

There seem to be n-gons (there should only be triangles!). Let me select one so you can notice it:


#4

I will now zoom in to one of the vertices which would make that face a n-gon if the vertex would actually belong to that face:


#5

But… That vertex does not belong to the long edge that defined the previously selected face! Hence, that face is not a n-gon but we have another problem: that vertex is “floating” atop the long edge and at the same time belongs to an edge overlapping the long one. Let me move that vertex down a bit so you can see it better:


#6

It’s not an isolated vertex, this happens in a lot of places. This armor plate is not a complicated shape, it’s actually flat with several (not many) protruding bits. I mean, I hoped splitting the models into smaller, simple parts would help solve this issue, but if I export the whole tank as a single model, combining all parts, I get exactly the same results.

There might be people who’d ask “why is this so important?”. Just a few reasons why:

  • Surface rendering inconsistencies: You can get the specular “reflection” look like cut along the overlapping edges of an otherwise continuous-looking surface, for instance.
  • Per-face normals wrong calculations: This produces dark areas in the inconsistent faces, leading to smoothing groups errors during previews and renderings (3ds max actually hates this). It can be fixed by recalculating the normals and killing the smoothing groups, but that fix doesn’t work with many overlapping edges/floating vertices.
  • Lighting artifacts: There can be “shiny lines” along the shorter overlapping edges; using per-vertex lighting (and I think we all do) can get very messy.
  • Shadow artifacts: Using shadow-casting techniques, the silhouette-defining vertices/edges must be consistent. There are times when this wrong mesh topology can create “holes in shadows”, areas inside projected shadows where there’s actually no projected shadow (think of a boolean substraction within the shadow).
  • Mesh Skinning problems: Be it rigid skinning or soft skinning, these vertices detached from large areas of our meshes are troublesome to weight and create unwanted deformations. If I pass meshes with this topology to a rigger/animator I might be killed on the spot.

These are indeed just a few reasons why this is actually a problem, you can come up with more. This tank I’m using as an example has an overall “boxy” shape, characters and organic models are quite a pain. As a final image let’s see the hull of this tank in UU3D with the “Degenerate 3D” edges automatically marked in red; the surfaces should be flat grey but you can also see the “smoothing groups” problem darkening some areas in an inconsistent manner. I mean, it’s consistent for this mesh topology but it really shouldn’t be happening. The model was exported as is from Qubicle 3, no other processing was applied:

So, any advice? How can I export my models from Qubicle without these artifacts so I don’t have to re-model them, UV-map them, make new textures and all?

Thanks in advance,
K.


#7

What a giant explanation :stuck_out_tongue: but the shadows are noticeable in unity 5 :confused:
I don’t think there’s a fix yet but with the amount of information i’m sure they’ll figure something out :smiley: Here’s the post about unity T-Junctions and edge bleeding


#8

Hi Dani,
If you’re referring to the dark areas in my last image, I may give you a hand with it: do not import the normals when loading the model into Unity, use “calculate normals” and they will look ok. This can also be done with previously loaded models. In other engines I’ve had to use a dirty trick: using emissive materials with the bare minimum emission value can do the trick when coupled with darker/lighter colors depending on face orientation (top being the lightest, bottom the darkest). This is a very limiting trick, as you can’t freely rotate the objects and the scenes must use a single directional light so everything will fit in, but as I’ve succesfully used it before I though it was worth mentioning.

Depending on the 3D software this “dark corners” problem can be solved by recalculating or forcing the normals (I prefer face normals over vertex normals) and getting rid of any smoothing groups. I’m aware 3ds max complains a lot in the process of doing so. This effect can be masked turning up the smooth/autosmooth values to 90 degrees (that’s a material, object or smoothing group attribute, depending on the chosen software), but when there are edges running too close to each other in such areas, the unwanted dark corners are still noticeable.

Anyhow, as a rule of thumb I rely on mesh information and UVs, calculate face normals when importing the meshes to the engine (where appliable) and create in-engine materials instead of importing them. Some engines won’t let you do so (HeroEngine and the like) but Unity will.

I’ll be having a look at the link you’ve posted, thanks a lot!


#9

Hi again.

I’ve checked and re-checked. I can’t find a solution by myself.
There are times where a projection (cubic or planar) could do the trick and solve my problem; but if I do so in Blender, I have to re-model what I’ve already done in Qubicle, get the UVs right and make a texture to map those UVs. That’s a pain, I can do so with a bunch of objects but not all of them. Another example, a container with “degenerate 3D” in red:

And now textured:

Simple geometry? This would be either two overlapping boxes or a box with two extrusions (4 if you take insets into account). And I still get two long inconsistent edges…
And most of my models are way more complex than this so they have more floating vertices…

Please… Anyone… @Admin… Help?


#10

Hi Kurim,

For our last game (Super Man Or Monster) we also used ‘optimized’ meshes in-game. For that project, I did not do the exporting myself, so I am not 100% sure why certain things were done.
However, we did not use the Qubicle optimizer for a certain reason (which I cannot remember but might very well be related to the problems you are experiencing).
We exported the ‘full’ unoptimized version to 3dsmax, and used the ProOptimizer modifier to do the optimizing, then export from 3dsmax to Unity using FBX.
It allowed us to do some parenting and pivot changes in 3dsmax ( :wink: ), but luckily we did not have to remodel everything.

No real solution without installing 3dsmax or finding some optimizer for Blender. Sorry :(.

Diederik / Xform


#11

Thanks Diederik!

I don’t know ProOptimizer but I’m searching for alternatives in Blender. Its built-in decimator does indeed fix the geometry but the texture generated by Qubicle becomes unusable. Despite common belief (grin) I’m not an artist myself and can’t think of a way to “bake” the unoptimized model’s texture into an optimized model’s UVs. If I ever find one then I’ll have to retouch it to avoid bleeding, I guess. But I’m still searching for a solution, too many models to handle and no time for it…

Kind regards,
K.


#12

This is kind of a deal breaker for the product. If the optimisation isn’t very good, it leaves a huge amount more effort to the user, if they even have any idea how to fix it in general.

Kind of sad no word is in from a developer on looking into this.


#13

Sorry guys, I was on vacation. Needed some free days after a very long year without a break.
I will be back on track on monday and will have a look at this issue


#14

Is there a solution for the problem allready? I have the same problems exporting from qubicle to blender and from qubicle to 3ds max. If this problem won’t be fixed the workflow of producing models in qubicle is greatly limited by the bad export.


#15

Still looking into it. Unfortunately not that easy to solve and will take some more time. This is the only part of qubicle that i haven’t written myself. But I will do my best to come up with a solution.


#16

Hi Jojoba,

tl;dr NOPE

Summing up:

  • I started this thread on May 12. Deadline: June 3.

  • The solution for the “dark areas” problem is recalculating the face normals in Unity; for other engines you’ll have to use another 3D app and recalculate/bake the normals before importing the models. In Blender and Ultimate Unwrap 3D this is achieved activating “Autosmooth” with a face angle of zero degrees. This pre-processing also works with Unity, but recalculating the normals once imported (remember: zero degrees) is less time-consuming.

  • Mesh topology is still a pain. Diederik mentioned ProOptimizer for 3DS MAX (May 18) and I had a friend of mine check on it, sharing his screen over Skype and all. Some models were handled OK, most weren’t. But what if it had worked? Would I have to pay for a MAX license? Hire someone using MAX to fix this? Not really an option for me…

  • Blender: The Decimate modifier fixes the mesh topology but the UVs get all messed up. The resulting meshes need reworking. If your models are single-colored you can go this way. Vertex merging and tweaking will be needed in complex shapes.

  • Caligari trueSpace: I’ve been using trueSpace since it was called Caligari One (Amiga) and keep a copy of trueSpace 7.6. When Microsoft bought Caligari they made it free, then shut it down. You can still find legit free copies of trueSpace online, I do recommend 7.6 set up as 6.6. The trick: import your object into Caligari, empty scene. Add a simple plane, move it away so it won’t touch your object. Booleans, Substract the plane from your object. All coplanar faces will be gone. The UVs will be messed up too. But the mesh topology is often better than what the Decimate modifier can achieve in Blender. Trying such an old trick from such an old piece of software tells a lot of how desperate I was.

  • Admin went back on May 27, he’d have a look at this issue on monday. Today… it’s monday, June 27.

  • We had our presentation on June 3, friday. We made two executable demos. One, the first we showed, was said to be “lacking content”: too few (optimized) models. So we showed the secod one, with lots of models exported straight from Qubicle. I had put light and shadow switches, the demo started off with both disabled. I admit it looked poor, and they pressed to see it with lights and shadows. I warned them, work in progress and all. Lights on: artifacts. Shadows on: artifacts. The recap email we received with the “sorry, we won’t fund your project” message said: “We feel the technologies you’ve chosen for such an ambitious project are not production-ready and need time to mature”. Input, VR HMD, tracking, networking… everything worked smoothly. But the rendering was poor as soon as lights and shadows were involved and we used “vanilla” models (imported from Qubicle). That would forbid us to load user-created content, unless we’d convert everything and that’s… Well, we won’t do it.

  • June 26, you (Jojoba007) ask. I’ve been about a month revamping stuff from our previous project to make another one. Less ambitious, single player voxel-based VR game. One month neglecting programming and designing just to fix the models. We’ve had a chance to pitch a different project and I’ve stayed away from voxels, just because of the pain. Maybe, just maybe when there’s no pain involved in the export process I’ll try again. For now me and my (humble, tiny team) have been and are spending loads of our time fixing geometry. I make the models in Qubicle, export them and then everyone else puts them into Blender and fix-fix-fix. Remodel. Remove UVs, create new UVs, create new textures, remap UVs. Just in case, I export 2 models: one to work on it and another one, totally unoptimized and using vertex colors, for reference; this way everyone knows what color goes where when making the textures. And then we have to triple-check every model, see if every face fits or if there are any wrong colors. “Pain” doesn’t even begin to describe it.

Hate the sin, love the sinner. I do love Qubicle. I strongly dislike what its mesh optimization force me to do.

Edit: While I’m spell-checking, Admin has replied. I haven’t changed a comma from my reply, just fixed typos. Hell when I grow up I want to be a real fixer, not this kind… (Warning: peculiar humor detected)


#17

Man, i am terribly sorry about that. Qubicle is a one man show so i can only do that much at a time. I have worked without a break for two years and i just needed some time to come down again. Again I am doing my best to come up with a fix as soon as possible.


#18

Dear sir, I am in pain. I’m tired and it sometimes feels like I’m living inside a Happy Tree Friends episode. I have found no other issues in Qubicle and I keep saying I love it. Honest. I could say “I can’t wait to see this issue fixed” but the fact is I will wait. Qubicle is the best option out there to craft voxel-based models, period. I know it’s been used to make quite a lot of games and most of them look ok. Maybe their engines, material shaders or lightning models somehow “hide” topology inconsistencies; maybe their models are split by colors or something, mine are not.

I’m not giving up. I keep working on a VR voxel game but it will take a lot of time if I spend my hours in Blender instead of programming and addressing design issues. Heck, I should finish the game’s website too…
Mine is a two man show right now, I can relate.

Best wishes, kind regards, keep it up :wink:


#19

Thanks for the feedback and nice words! I know I repeat myself but I’ll do my best to help you and fix things. Good lick for your game and feel free to post stuff. Iam always curious what my customers are creating. Unfortunately i don’t have time to desin myself


#20

Just got this program a week ago. I noticed this last replied on Jun 16. Any fix for this yet? Been looking everywhere for a fix but can’t seem to get a good fix.