[WIP] MeshDebugger BETA

WeMighAsWell... MeshDebugger BETA
​

So there you are procedurally generating meshes. Have you ever got a generation result that didn’t fit what you expected? You ask yourself: “Did I get the vertex-indices right? Are all the triangles clockwise?” etc. With procedural generation of meshes comes the need to thoroughly examine the results…
Or maybe you got some imported 3D-models and want to have a look at the quality of the meshes…

Our MeshDebugger gives you a bunch of Gizmos to visualize all the information your Unity-Mesh holds!

Features​

• Visualize Vertex information
  • VertexCloud Drawing (Now with billboards)
    
  • Local/Global Positions
  • Indices
  • Normals
  • UVs
    • Draw triangles u/v --> red/green (new)
    • Draw triangles u/v --> black/white (new)
    • Draw uv-TestTextures (put your own in Resources Folder) (new)
  • Hide/Include unused vertices (new)
• Visualize Triangle information
  • Triangle numbers
  • Referenced vertices
  • Normals
  • Tangents
  • Triangle-Gizmo
• Visualize Mesh information​
  • Axis Aligned Bounding Box (AABB)
  • Oriented Bounding Box (OBB) (new)
    
  • Seams
  • Submeshes
  • Surfaces
  • Triangle-Quality
• Different Culling-Modes (new)
  • No Culling
  • Object related Culling
  • Global Culling
• Limited Draw Mode (new)
  • Selection Areas (Boxes & Spheres)
  • MouseSphere (Drawing around mouspointer)
• Selection Options (new)
  • Freeze Selection (new)
  • Include MeshFilter-Meshes (new)
  • Include MeshCollider-Meses (new)
  • Include Child-GameObjects (new)

Product Website

BETA-Release
We could need some feedback!
All feature requests, bug reports, general critique or just some cat-pics are welcome!
If you want to join the BETA, please contact us under:
info@WeMightAsWell.com


Info and Contact
Web: www.WeMightAsWell.com
eMails: info@WeMightAsWell.com
support@WeMightAsWell.com
Twitter: @WeMightAsWell_
Youtube: www.youtube.com/c/WeMightAsWell
Google+: plus.google.com/+WeMightAsWell​

Known Issues​

• Exceptions with malformed or not completely filled meshes (for example: no tangents set, but want to show)
• Not sure if tangents drawing is correct
• Performance with high poly meshes (still a lot of optimization todo)
• Label culling not working without a proper collider (MeshCollider is recommended)
• SceneView orbit navigation by pressing Alt-Key causes perfomance issues (just press Alt-Key once at the start of the orbit)
• Limited Draw Mode: Boxes and sphere selection doesnt get serialized yet
• Object Oriented Bounding Box doesnt work with scaled objects yet
  
• Different culling modes: some border triangles are not culled correctly
• Some mesh function should be drawn without visibility check (for example seams should always show for the whole mesh)

 

As someone who does a lot of work with procedural geometry, this could be a lifesaver! Thanks!

 

hi maxwelldoggums, thanks for the reply!
Some testing from someone with a background in procedural geometry would be great! Please shoot us an email if you are interested: info@wemightaswell.com

 

Tester here.
I have a windows machine and two mac machines I plan to do testing on, but have only managed on the windows machine so far, relevant stats below.
Windows 8.1 64 bit
16GB RAM
single ASUS R9 280X series video card
solid state hard disk

Off the bat I'm seeing really good performance. I have to at least be displaying three of your heavier draws to get any slowdown, even when my code is running beside it. I was able to get up to 10 different types of debug info displaying at once before it started to lag unbearably, and by then there was far too much information on the screen to read anyway.

On a related note, I would like to put in a suggestion to Isolate drawing of the currently checked features to particular areas of the mesh. I'm not sure what ways are possible through your current structure, but a few ways to approach it come to mind. First thought is a sort of local/global position region that can be set to have debug info on. Perhaps track a point and a radius or a bounding box within which debug info is displayed. I can see a lot of times where you have an isolated issue in a generated mesh that this would help with. Alternatively being able to choose ranges of the tris/verts to display info. And by range I mean range of number. This might be a more feasible to implement feature, and would still provide the desired effect of reducing the amount of info displayed to the area you are worried about.

I have run into what I presume to be a bug where any part of the mesh that is too directly facing me does not get certain information displayed. The options for Mesh Seams; Vertices Indices, LocalPositions, GlobalPsitions, Normals, UVs,(I have thus far lacked a propper test forUV1s and UV2s); Triangles Numbers, VertexIndices, Normals, Tangents, and colored triangles are all experiencing this issue on my windows machine. I have included a screenshot of the issue in colored triangles mode and seams mode to help explain.

That is all the testing I have time for today, but I hope to have a bit more time as the week progresses.
~Tom

 

Hi Tom,

First of all: Thank you for the first testrun and your feedback!

Great! Thats what we are aiming for. We are still working on some optimizations.
Have you tested the MeshDebugger only with the objects seen in your screenshots? Have you tried some higher-poly objects as well?

Regarding your suggestion to provide the option to isolate drawing of the debuginfo to specified areas:

• We already considered to provide some kind of “magnifiying glass” for the mousepointer to isolate the information (this should be a straight-forward implementation considering our current structure).
• Your suggestion to specify local/global regions with spheres or bounding-boxes is also great and we will look into that…
• To Specify the ranges of tris/verts could also come in handy (maybe in the next update)

Related to the “bug” you experienced:
At the moment we have trade-off with our label-culling-mechanism. Though we are not sure yet, but it might explain your result. Our label-culling-mechanism (which uses the collider) is supposed to cull all the verts/tris where the view is blocked. When selecting multiple objects, the view on some parts of some objects might get blocked so we culled them as well. Otherwise you would have a lot of overlapping labels. This sometimes results in culling too much information. The attached screenshots shows what we expected to happen.

We could provide the option to toggle between culling globally and object-related (and disable culling completely). Could this fit your needs?

Looking at your screenshots we have some questions to narrow down the cause of the visual result:

• What kind of collider are you using? Are you generating a (simplified) meshcollider that is different from your generated mesh?
• Do you have more than one scene-view open? We have not yet looked into that…
• Looking at the seams-screenshot:
  • Are you generating triangles that lie “inside”?
  • Since almost every triangle is drawn with seams: are you creating separate vertices for every triangle? Or are those fragments supposed to be split-off at some time? (you can mail us directly if you don’t want to give away more detailed information on your project here)
  • We can’t really perceive which of the objects in the scene are selected (the spheres)

Maybe you could send us your test-scene (without you generation-code of course)? This would really help us to examine the problem.

We are working on your suggestions and will send a new version ASAP…

Dennis - WeMightAsWell

 

I think I see what happened. I was generating a 3D Navigation mesh for a flight simulator AI based on objects in the terrain. The mesh was just a visualizer to help find mistakes in my AI, and as such had no collider. That said, the objects it is based on did have colliders. If I either remove the objects or add a collider to the generated mesh your tool displays correctly. In answer to your questions, there are multiple scene views(and a game view) open when I am looking at it, though with the collider corrections this is not an issue. There are no internal triangles(I exported the nav-mesh out to blender to double check, that was actually one of my first thoughts as well). As for what was selected, only a single mesh, which is the rough floating shapes.

TL;DR: it seems to have been a combination of there being overlapping colliders in the scene and the mesh not having a collider attached to it.

Perhaps if you can detect that the currently selected mesh doesn't have a collider attached to it you can turn off the culling?

In a related issue, when I attach a mesh collider to the object being debugged unity slows down significantly. Neither your render nor the collider render seems to be slow, but the two of them together seems to be giving it a bit of trouble. This test was performed on my work machine, which is a year-ish old macbook pro with a reasonable nvidia card and 8GB ram, for what it's worth.

In regards to higher poly meshes, yes, I've run several character and Item models through the tool. All of them have run through fairly well, though I haven't had a chance to test texture mapping information yet. The main reason I didn't include screenshots of them was I didn't see any issues and some of them are destined(I hope) for game usage. The issue I reported likely didn't show up because I was looking at them without any other colliders in the scene at the time.

I also like the idea you discussed of some sort of 'magnifier' or other basic window to isolate an area for debug info. now that I see you are culling based on colliders I can at least sweep all the back facing information out of view by adding a mesh collider. That said, I am worried that there may be some internal issues on generated meshes that wouldn't show up as a result.

Do you have any further particular tests you'd like information on, or should I just keep throwing things at it till something breaks?
~Tom

 

Oh! I meant to ask. Your tool only looks at the mesh data correct? It shouldn't be affected by Unity normal maps and such should it?

 

Hi Tom,

you are right, multiple overlapping colliders would explain this behaviour. We are currently developing on a solution for selecting more culling modes (use all colliders in scene/just use the objects own collider/no culling at all).

Regarding your second question: Yes, we currently only use the mesh data itself, normal maps (or other texturebased data) are not considered. Would that be a feature you'd like to have? I'm not sure how to visualize this data tho, any suggestions?

Some of your suggestions are already in development/ready, we will send you a new version later today or tomorrow! We will put an update in this thread what could be tested then

Thanks again for your feedback!
Marco - WeMightAsWell

 

I actually was asking because I have some meshes that are normal mapped that I hadn't tested with because I wasn't certain what expected behavior was. I'm not certain you would want to do anything with normal maps. The only really useful things I can think to show are highlighting edges when the normal mapping suddenly harshly changes, an indicator that your normal map isn't correctly mapped to your UVs. even that functionality is perhaps not as useful and not as related to the rest of the tool as it could be.

You also seem to mostly be directed at procedurally generated meshes, so I'm not sure most end users would be working with normal maps.
~Tom

 

The new BETA version 0.2 is released!
All tester should have received an eMail, if anyone wants to join testing please let us know!

Changelog:
* Verion BETA 0.2.0.0 (01/10/2015):

• Limited Draw Mode introduced
  • selection by boxes or spheres
  • ISSUE: boxes and sphere selection doesnt get serialized yet
• VertexCloud Drawing (you need to disable the MeshRenderer to see it)
• Fixed Bug: Surfaces with only one triangle now are drawn correclty
• Option to include/hide unused vertices
• Introduced Object Oriented Bounding Box
  • ISSUE: doesnt work with scaled objects yet
• Different culling modes: No Culling, object related culling, global culling
  • ISSUE: some border triangles are not culled correctly
• Fixed Bug: No nullreference exception when selected object is deleted
• moved namespace to WeMightAsWell.MeshDebugger
• added EditorPrefs prefixes to avoid compatibility problems with other extensions
• ISSUE: some mesh function should be drawn without visibility check
  • for example seams should always show for the whole mesh

We will update this thread with our further plans for development soon.
Any suggestions are welcome

Marco & Dennis - WeMightAsWell

 

Sorry it took me so long to get back to you, work has been rather hectic the last few weeks.

For starters, 0.2 has TREMENDOUSLY better feedback on what is happening. The UI in the menu is far clearer and very helpful. I'm seeing a lot of new useful features here.

Love the introduction of the color coded information at the top of the menu. I nearly made the same mistake as last time forgetting about colliders, but it alerts you right away.

I've mostly found the default culling mode to be what is most useful, but having the options listed makes it a lot clearer what is going on and why. Now that I know how it works I haven't had any other overlap issues.

Object oriented bounding box is actually a lot more useful than I was expecting it to be. I found some of my calculations for nav mapping work better at an angle to the target. I don't know how many other specific problems it will help with, but it already changed some of my approach on that project.

Limited draw modes are great, possibly the most impressive and useful change for me in the update. I'm not exactly certain how you've set them up on the back end, but having them plug right into unity's manipulation controls makes them intuitive and easy to set up. Mouse sphere is really helpful as well. I did run into some trouble here with high poly meshes though. High poly meshes cause a bit of lag even when there is nothing in a selection area to be drawn. Turning everything to be drawn off fixes this, but it means you have to keep switching this on and off to move the areas. This isn't such a big deal, but it ruins the mouse sphere. The mouse sphere sometimes will even loose track of your mouse entirely while browsing a high poly mesh. It still keeps moving around as your mouse moves, but sometimes it will be functioning at a large offset.

Point cloud is super useful for procedural meshes, especially in conjunction with vertex normals you can get a really good idea of what is going on without having to render much. You've also got some great color information going on with normals and tangents, in a lot of my testing I would just turn off the mesh and use your debug information.

I notice that point cloud, submeshes, and surfaces ignore the limited draw mode specifications. I don't know if it is intentional or not, but I thought I'd point it out.

I'm not getting any errors or exceptions thrown still, I may try it on some other meshes this evening though.

In short this version is a major improvement, whether in terms of clearly showing what is going on in your mesh, or in terms of understanding how to use the tool itself.
~Tom

 

Hello beloved testers!
you should have received the new BETA version 0.3 of our MeshDebugger, here the changelog:

* Version BETA 0.3.0.0 (01/27/2015):

• ChangedCheck for includeVertices toggle, enabling it shows result instantly now
• Fixed SurfaceCalculation, so it doesn't crash with big meshes anymore
• Major GUI overhaul with more customization options
• VertexCloud now can draw billboards, so its more visible
• VertexCloud is culled now
• Added a freeze selection function
• New option to include child gameobjects
• New option to include MeshColliders
• Added UV debugging via UVTestTextures
• Included a check, if the mesh has a non-triangle topology
• Lots of optimizations

Please let us now if there are any issues...

Some questions:
What do you say about the new/extended GUI?
Are the customization-options "overkill" or do you appreciate having these options?
Are there any other customization options you would like to have?
What do you say about the performace on your machine?
Are there changes of some features good/bad for your needs?
Are there any Unity exceptions (or other) thrown while using the extension?

At what price would you consider buying the final version in the assetStore?

Thanks for your testing,
hope you enjoy our work,
Dennis & Marco - WeMightAsWell