To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 10099
10098  |  10100
Subject: 
Re: Rendering implementation details
Newsgroups: 
lugnet.cad.dev
Date: 
Tue, 25 Jan 2005 19:26:45 GMT
Viewed: 
1901 times
  
Okay.... having had a day to think about it and a night to sleep on it,
I think I've figured out something....

But it would only work if the optional lines were incident to edges of
polygons that are part of the object being drawn.  I'm not sure if one
could always make that assumption.

But the idea I was envisioning was something like this...

During the initial processing of the file, for every optional line in
the object, find the two polygons in the file which share that edge, and
associate those two polygons with that line.

During rendering when any optional line is encountered, then for both
polygons that the line is associated with, take the dot product of its
outward surface normal and a vector pointing directly towards the viewer
(or viewing plane, if an orthgonal projection is being used).   If one
dot product is less than or equal to 0 and the other greater than or
equal to 0 then draw the optional line, otherwise both faces are back or
front facing and the optional line should be omitted.

This incurs the overhead of 2 transformations per optional line (one for
both polygons on either side of it), rather than the 4 I was mentioning
before.  I'm not sure if it's an acceptable improvement or not.

Of course, this would only work at all if all optional lines happened to
be incident with polygon edges elsewhere in the object, which isn't
strictly required by the format, so I can't say I'd expect it to work
all the time.

A variation on this, which I am pretty sure _would_ work is to not draw
optional lines at all, and perform the above test on all edges in the
object which are not incident to any mandatory lines.   This effectively
makes a sillouhette for the object, and would be drawn in the color used
for edges based on the edge color for the polygon that is facing front
(which would be the whole object if it were all one color).   The
downside to this approach is that it would almost result in more
transformations, but at least it does not make any assumptions about
what may or may  not be in the file.

>> Mark



Message has 2 Replies:
  Re: Rendering implementation details
 
(...) 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 (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
  Re: Rendering implementation details
 
(...) What you are describing is in fact a very old and basic edge rendering algorithm, which can be found in most detailed textbooks on computer graphics. CAD style and wire frame rendering went out of style during the 90's, so some recent "fancy (...) (20 years ago, 29-Jan-05, to lugnet.cad.dev)

Message is in Reply To:
  Re: Rendering implementation details
 
(...) I'm not sure it's possible to implement for real without serious slowdowns. It might be possible to implement in a vertex program, but I haven't studied vertex programs, so I really don't know. (I'm pretty sure you can't throw out a vertex (...) (20 years ago, 25-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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR