Can it not be coded?

Playdo

I don't get it. One of my pet hates with max is that ignore backfacing only works if the surface is facing away from the viewport
(self explanatory). But what about the majority of the time when there are vertices behind the surface you're woking on which get selected because they're not backfacing?

Viewport clipping's a pain to keep working with and each selection I make I'm checking the 'vertices selected count'. Is it really that hard to code it so it won't select vertices behind a polygon? Or has a script been written for this that I've missed?

DarthNater

I believe ignore backfacing works the same way backface culling does by using the face normal to determine if it's drawn (or selectable) or not. This is why it's allowing these verts to be selected. Would it be hard to code something like that? Probably not, you'd just have to check if those verts are behind the drawn faces. I haven't seen a script like this before though...

FicWill

This is possible, but it's slow. I wrote a script a while back that did a per-pixel test for selection, and it worked like so:

Duplicate all scene geometry into separate polygons
hide everything else
Color these separated polygons each with a unique color (255*255*255) possibilities
Don't use the max background color, or the wirecolor of anything in the scene, or the viewport text color
capture a bitmap of the current viewport
scan the bitmap and gather the pixel colors into an array (this is the slow part)
derive the poly selection from the array

When it's all set up, it's one click and takes about a second in max to run. I used it a couple times to remove non-visible (not just backfaces) from distant scene buildings, etc.

eld

It shouldn't be an issue really, backface ignore in blender will make only the visible polygons/vertices/edges selectable.

I'm pretty sure other applications do it properly aswell.

Playdo

eld wrote: »

It shouldn't be an issue really, backface ignore in blender will make only the visible polygons/vertices/edges selectable.

I'm pretty sure other applications do it properly aswell.

Yeah, you'd think so, not in Max though. The Ignore Backfacing button is basically pointless in Max, imo.

@FicWill: I'm not a coder. I was hoping something was about

r_fletch_r

FicWill it doesnt need to be that slow its just the way you are approaching it

Create a bitmap the size of the viewport
get forward facing polys.
get verts from forward faceing polys.
do a intersect ray to each vertex, get the hit and compared the distances from the hit to the screen and the vert to the screen. if they are the same then the vert is visible.

draw each seen vert as a rechtangle of 2 or 3 pixels into the bitmap using a colour derived from its index.
Update when the view is tumbled or geo is edited
When the mouse is clicked sample the colour from the bitmap using the mouses X Y
Vertex index = Colour sampled

I havent check yet but id imagine maxscript has a callback for view changes. that or you could store the views transformation matrix in a global and attach a callback to the screen redraw then compare the current TM to the stored one

Michael Knubben

Selection Highlighting in max makes selection a lot more reliable, but then selection works completely different from how it normally does (holding ctrl without clicking flags everything you pass over with the cursor to be selected when you click)
If only it worked more like Silo's selection highlighting.

Yozora

MightyPea wrote: »

but then selection works completely different from how it normally does

One of the many great "features" of Max!

mLichy

There are MANY things in max that could be improved upon, but instead they add new shit that doesn't really matter, and leave stuff broken or un-reliable. They have made some aspects better, but I won't hold my breath for them to fix the other tools.

r_fletch_r

Im going to regret saying this but since installing .Net 4.0 im digging the ribbon. The default position is shit but Float a few toolbars go into expert mode.. JOY

bbob

I would have to agree with r_fletch_r

Michael Knubben

I like the ribbon, yeah. I'd want to get in there and pretty much redo it (cut whitespace, for one!), but I do like it.
Oh, and for it to be truly useful, it would have to work for more than just edit poly. For instance on curves etc.. as well

FicWill

r_fletch_r wrote: »

FicWill it doesnt need to be that slow its just the way you are approaching it

Create a bitmap the size of the viewport
get forward facing polys.
get verts from forward faceing polys.
do a intersect ray to each vertex, get the hit and compared the distances from the hit to the screen and the vert to the screen. if they are the same then the vert is visible.

draw each seen vert as a rechtangle of 2 or 3 pixels into the bitmap using a colour derived from its index.
Update when the view is tumbled or geo is edited
When the mouse is clicked sample the colour from the bitmap using the mouses X Y
Vertex index = Colour sampled

I havent check yet but id imagine maxscript has a callback for view changes. that or you could store the views transformation matrix in a global and attach a callback to the screen redraw then compare the current TM to the stored one

I totally get what you're saying. Unfortunately in practice that doesn't always work. There's no guarantee that a face's verts will be visible. It's entirely possible (and common) for part of a polygon to be visible, yet all its verts are intersected into other geometry. While it'd be great to do a per-vert search, per-pixel is the only way to get a perfect result.