Subject:
|
Re: Rendering implementation details
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sat, 29 Jan 2005 22:41:11 GMT
|
Viewed:
|
2053 times
|
| |
|
|
In lugnet.cad.dev, Mark Tarrabain wrote:
> Don Heyse wrote:
> > I don't see it. Are you sure this works in the perspective projection?
> > Because I can't quite figure out what the magic view vector is in that
> > case. I think you'd need to calculate one view vector for each edge
> > endpoint, which brings the number of transformations back up to 4.
>
> Actually, one can bring the number of transformations down to 1 for the
> entire _object_. Interesting what can happen when an idea sits in the
> brain and percolates for a couple of days.
>
> A new idea I had was to just transform the camera position once for each
> object in the file (simply by using the inverse of the matrix that the
> object is using). There's no need to transform the face normals at all
> from what they are in the file because one would be using an eye
> position in the same space as the part itself. The vector towards the
> eye would just be the vertex at one end of an invisible edge subtracted
> from the appropriately transformed camera position, so there's basically
> just one vector subtraction per edge considered.
Ok, I drew a better picture (2 planes in space and a floating eye) and
I'm starting to see. Maybe you're onto something. It takes 2 surface
normals and one point on the edgeline to divide space into 4 quadrants.
Then you only need to figure out if the eye is in either of the 2
quadrants where we need to draw the edgeline.
Yeah, if the dot products (between the surface normal and any
eye-surface vector) have opposite signs then the eye is in one of
the draw quadrants. And since both edgeline end points are on both
planes, you can use either one for the eye-surface vector. Yes, I can
see it! And maybe transforming only the eye makes sense too.
But hmmm, you can also state it this way. If one surface is removed by
backface culling, and one is not, then draw the edge. It all comes back
round to BCF. You've gotta have the winding fixed for the normals to point
the right way. But once you've got that, you can use the display list
driven magic halo or cartoon rendering method and let the opengl driver
do everything automatically with backface culling in the opengl pipeline.
> Further, it doesn't even matter if the orientation on the polygons is
> the same... during initial processing of a part file, one can examine
> each edge in the file. If an edge is part of two polygons but its
> vertices are in the same order both times then that means that the two
> faces are being described with opposite winding. So it's always
> possible to find out if adjacent polygons are facing opposite directions
> based on their normals' dot products with a vector towards the viewer.
>
> So edge highlighting is entirely possible in an efficient way even on
> non-BFC compliant parts. And with a little more up-front work, you
> could even reorient all the polygons on an object to have the same
> winding and determine which direction it was, making any part BFC
> compliant at load time.
But wait, If you can make a program to fix winding on the fly then make
a tool for ldraw.org so it can be added to the part submission process.
Then we can run it on all the parts so nobody ever has to fix them on
the fly again. That'll make *all* the renderers faster.
Whatcha think?
Don
|
|
Message has 2 Replies:
 | | Re: Rendering implementation details
|
| (...) It doesn't matter, actually. In one way or another, optional lines are required. In general, the "magic halo" effect only highlights _outside_ edges, but for a non-convex object, that won't necessarily be adqeuate. You can't even get away with (...) (20 years ago, 30-Jan-05, to lugnet.cad.dev)
| | | BFCFixer
|
| (...) Well, I had some spare time today... so I wrote one. It goes through a single LDraw part file and reorients all the polygons in it to have the same winding. It comprehends the notion of subfiles and already BFC compliant parts, and puts the (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Rendering implementation details
|
| (...) Actually, one can bring the number of transformations down to 1 for the entire _object_. Interesting what can happen when an idea sits in the brain and percolates for a couple of days. A new idea I had was to just transform the camera position (...) (20 years ago, 29-Jan-05, to lugnet.cad.dev)
|
22 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
