Z-shading in edit mode

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

coelurus
Posts: 0
Joined: Sat Jun 18, 2005 9:21 pm

Z-shading in edit mode

Post by coelurus » Sun Jun 19, 2005 4:52 pm

My brother and I have added Z-shading in edit mode for the 3D viewports. This means that it's a lot easier to see which vertices are close and which are far away, atleast we think so :) . It's a hack that uses some OpenGL-tricks so that we didn't have to change a lot of functions to set the colors. The patch alters very little of the existing source code, it merely adds the two color-states, the Z-shading routine and changes the mapped-edges function in DerivedMesh.c plus adds some UI entries.

Only a source code patch, we don't have access to any Windows computers and compilation under Linux is pretty straightforward.

Would be thankful for any input :)

Page with screenshots, patch and some notes:
http://coelurus.thorntwig.se/

EDIT: Maybe this topic would fit better in the 'Interface & Tools'-section?

bullx
Posts: 0
Joined: Mon Jan 05, 2004 9:25 pm

Post by bullx » Sun Jun 19, 2005 5:03 pm

really nice, it seem really good to me.

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Thu Jun 23, 2005 10:27 pm

I haven't checked out the patch yet, but I think that this is a nice improvement. Even with the ability to hide/unhide selected parts of a mesh, the 3D windows can get clutter and confusing rather quickly.

TorQ
Posts: 29
Joined: Wed Jan 29, 2003 2:03 am

Post by TorQ » Thu Jun 23, 2005 10:35 pm

Nice work! If you are feeling ambitious we also need the ability to see textures in Edit Mode. That would be BIG!

TorQ

coelurus
Posts: 0
Joined: Sat Jun 18, 2005 9:21 pm

Post by coelurus » Thu Jun 23, 2005 11:23 pm

Before we do anything ambitious, we have to fix one annoying little bug; there's a problem selecting vertices in concave areas with the patch applied and solid faces enabled, The vanilla version of Blender does not show the same problem. The funny thing is that selection works as normal without faces and we haven't touched that part of the code... Gonna look into this asap.

Anyway, the patch is very useable right now and it helps a lot in complex meshes with lots of depth.

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Fri Jun 24, 2005 12:27 am

When reading the following please note that I am a newbie to Blender development. So please forgive any ignorance on my part. :)

I took a quick look at the code and I wanted to get clarification on one thing:

It is not clear to me why you need to calculate the range of Z values for the mesh. I would think that the Z values that come out of the Model View Transformation would be enough. I am assuming that the camera(for the window) is place at <0,0,0> with the view plane at z=1 or something similiar. Does this make any sense?

Also, I think that you can move glDepthFunc() and glShadeModel() calls into drawobject.c before and after you make the call to draw the edges.

coelurus
Posts: 0
Joined: Sat Jun 18, 2005 9:21 pm

Post by coelurus » Fri Jun 24, 2005 2:10 am

About the Z-values:
If we'd use absolute Z-coordinates to calculate colors, then we'd need to interpolate over the entire span of the Z-buffer and the shading of the object would only cover a fraction of the entire shading. We search for the extreme values that define "the boundary where the major chunk of vertices start" (you could say "near" and "far" distances) and interpolate only over the span that the mesh covers in distance. For more information regarding the search, read the notes on http://coelurus.thorntwig.se/

Second question: Blender uses a whole heap of cases to draw things, so instead of figuring out all calls to MappedEdges, we just put glDepthFunc and glShadeModel straight in there. I should note that glDepthFunc is pretty unnecessary and glShadeModel is more related to the edges rendering routine than the higher level object renderer.

malCanDo
Posts: 1
Joined: Mon Oct 21, 2002 1:44 pm
Location: Ireland
Contact:

Post by malCanDo » Fri Jun 24, 2005 2:47 pm

> Nice work! If you are feeling ambitious we also need the ability to see textures in Edit Mode. That would be BIG!

Seconded... this would be very useful!

Also, in the UV texture panel, it shades the texture area with a slight blue tint... if you have a model with many selected faces, falling into the same UV range, the entire texture comes out blue ( 100% tint )... it would be useful to have a limit on the amount of tinting.

Regards...
Mal

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Fri Jun 24, 2005 4:11 pm

About the Z-values:
If we'd use absolute Z-coordinates to calculate colors, then we'd need to interpolate over the entire span of the Z-buffer and the shading of the object would only cover a fraction of the entire shading. We search for the extreme values that define "the boundary where the major chunk of vertices start" (you could say "near" and "far" distances) and interpolate only over the span that the mesh covers in distance. For more information regarding the search, read the notes on http://coelurus.thorntwig.se/
I can see where a linear mapping of the Z values to colors wouldn't work so well, but what about a non-linear mapping? How about an exponential like f(z) = e^(-c*z); c, z > 0? Maybe something of the form 1/z like f(z) = c / (z + c); c, z > 0? In both cases, the view plane is assumed to be at z = 0 and 'c' would control the distribution of colors over the positive Z values. The first function is more OpenGL friendly since it already provides an exponential fog mode. The second function approaches 0 slower than the exponential. Closer edges would get more shading and further edges would get less shading. To me, this seems logical. What do you think?

I guess that I am just stuck on thinking that it would be cool if a certain shade always corresponed to a certain depth. In theory, that would improve the user's depth perception in edit mode.
Second question: Blender uses a whole heap of cases to draw things, so instead of figuring out all calls to MappedEdges, we just put glDepthFunc and glShadeModel straight in there. I should note that glDepthFunc is pretty unnecessary and glShadeModel is more related to the edges rendering routine than the higher level object renderer.
Agreed. I didn't examine the function closely enough. For some reason, I originally thought that it was drawing only a single edge.

coelurus
Posts: 0
Joined: Sat Jun 18, 2005 9:21 pm

Post by coelurus » Fri Jun 24, 2005 7:19 pm

Our idea for Z-shading is based on that the shading is relative to the local mesh in order to see where vertices are in the mesh. For complex, small- to mid-sized meshes, shading over the entire range of the Z-buffer will wash out the shading way too much even when using non-linear curves. Local mesh shading is generally more practical for modeling and Z-shading was implemented to be as useful as possible :)

Fogging would get rid of all glColors, I used the fog-color to send one color to the function but I didn't think of actually using it directly ;) Ah well, that means we got something for the next update on the patch. We're a little busy right now so the selection-fix could be delayed.

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Fri Jun 24, 2005 8:11 pm

Our idea for Z-shading is based on that the shading is relative to the local mesh in order to see where vertices are in the mesh. For complex, small- to mid-sized meshes, shading over the entire range of the Z-buffer will wash out the shading way too much even when using non-linear curves. Local mesh shading is generally more practical for modeling and Z-shading was implemented to be as useful as possible
I certainly can see small meshes being a problem no matter how the Z's are mapped to colors. Also, small meshes is probably where this patch is the most useful. Yeap, I think that I agree with your approach to the problem. Good job! :D

Now that I fully understand the patch, I will take another look at the code and let you know if I have any suggestions.

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Sat Jun 25, 2005 12:10 am

I took another look at the patch now that I have been enlightened. :lol:
My sugguestions are:

1. Consider transforming all the Z's(and only the Z's since you are not using X and Y) only once in emDM_drawMappedEdgesEM and passing them into calcExtreme. I think that this would simplify the logic overall and make the code easier to understand.

2. Loop over the vertices(or Transformed Z's if you did the above) in calcExtreme instead of the edges. I think that you might be missing vertices if an edge was only connected at 1 vertex.

3. I would initialize minZ/maxZ to the first Z values instead of 1e9.

In calcExtreme, I can't figure out what's going on with diagramSpans[]. I thought that it defined the 'buckets' into which the Z values fell and diagram[] kept track of the number of Z's in each 'bucket'. If that is the case what is the purpose for these 2 lines.

Code: Select all

if (vert[2] < diagramSpans[i][0]) diagramSpans[i][0] = vert[2];
if (vert[2] > diagramSpans[i][1]) diagramSpans[i][1] = vert[2];
This would change the size of the 'bucket' correct?

Of course, these are only suggestions. This is your story and you can tell it anyway you like. I know how some people feel about their code. :)

coelurus
Posts: 0
Joined: Sat Jun 18, 2005 9:21 pm

Post by coelurus » Sat Jun 25, 2005 12:45 am

(Hans, the Z-shading coder): It's good to get some feedback, as I said the patch is very much a hack so any ideas for improvements are very welcome :)

1. I haven't got around to do any optimizations or cleanup of the code but this is definitely something I'll fix.

2. The calcExtreme-function was almost a straight copy of the MappedEdges-routine, I just changed what was needed to be changed...

3. I know, a "hack" ;)

4. The thing is that the columns in the diagram are evenly spread and each column is a 'sizeable bucket'. If we'd use the discrete columns directly, then there'd be a lot of popping colors when meshes are rotated. The sizeable buckets define the boundaries of each columns in floating point to fake better resolution, therefore I look for the min and max Z for every column. The best way would be to fit a curve into the data and solve for intersections but that's just overkill...

We're glad to see that this patch is of interest :)

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Wed Jul 06, 2005 8:36 pm

I tried out some ideas related to this and had some success. Here are the things that I attempted:

1. Interpolated the edge's width so that the edges in the front of the mesh are thicker than the edges in the back of the mesh. I did this by breaking the edges up into segments since OpenGL doesn't let you interpolate a line's width. There might be some better ways of doing this such as replacing the line with a thin polygon.

2. Used a local shading scheme, along with with Z shading, to vary the color of edges that are close in Z. Just simple face normal dot product stuff. The problem is that only certain meshes benefit by using this.

3. Just like shading with color, use alpha transparency to fade the edges as they fall into the distance. I threw this in as quick test not really thinking that it would help out a lot, but I was surprise by the visual improvement.

I will post the code and a picture in the next couple of days. I also tried some curve fitting ideas, but none of them have worked out as of yet.

eric.m.forsythe
Posts: 0
Joined: Thu Jun 23, 2005 3:26 pm

Post by eric.m.forsythe » Wed Jul 06, 2005 8:52 pm

I was just wondering... What do other 3D modeling programs do to make the viewing of complex meshes (especially wireframes) easier to understand? Do they do anything? Is this even a problem for most people?

I have used several modeling programs over the years, but only Blender recently. I can't seem to remember if any of them dealt with this issue at all.

Post Reply