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 / 9601
9600  |  9602
Subject: 
Re: surface normals and vertex normals for OpenGL
Newsgroups: 
lugnet.cad.dev
Date: 
Sat, 13 Mar 2004 07:48:48 GMT
Viewed: 
4964 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
> I won't argue with your clarification, but I will point out that it would be
> more difficult for a renderer to perform this feat, particularly one that is
> designed as a real-time renderer, and therefore presumably has rather serious
> limitations on the amount of pre-processing being done.
> 
> Take for example the crater baseplate (I'll be conservative and go on the
> assumption we'll just skip processing all the studs, because we already know
> which way their polygons point.)  That still leaves us with a whole mess of
> polygons, and we have to determine connectivity information for all of them.  I
> suspect this will take a while.  (I will grant that in the current parts library
> this part is pretty much a worst-case scenario.)
> 
> Add on to this the fact that LDraw parts do on occasion contain T junctions, and
> you see another problem.  Add onto this the fact that since you know that not
> all your surfaces are going to be closed, you're going to have to somehow decide
> which way is "out".  I'm not entirely sure this can be done automatically in a
> timely manner.  (I realize that if you cast enough rays from outside the object
> into the object, that you'll eventually know the first hit side for every
> visible polygon, and any polygons that don't get hit are never visible and can
> be thrown out.  However, I don't think this can be done in a timely manner.)
> 
> Put all the above together, and I personally suspect my original claim that
> determining the correct normals is "pretty much impossible" is fairly accurate,
> at least in the context of a real-time rendering program.  Note that if someone
> does implement a solution that works, I'll gladly admit that I was overly
> pessimistic.
> 
> Having said all that, I wholeheartedly agree that it should be possible to write
> a batch program that process LDraw parts as you suggested.  I believe that the
> level of difficulty is still relatively high, but I do agree that it's possible.
> Additionally, I think with a lot less work a program could be produced that
> worked on a majority of the parts in the library.

With the use of a point hash table, it should be possible to do all
of the analysis in linear time proprotional to the number of points
in the object.  So, I guess I disagree with you.  Not that it
particularly matters, until somebody actually writes the code,
it is just my opinion vs. your opinion.  Currently, your opinion
carries a bit more weight since you have actually taken the
time to write code that processes LDRAW files and I have
not (yet.)

-Wayne



Message is in Reply To:
  Re: surface normals and vertex normals for OpenGL
 
I won't argue with your clarification, but I will point out that it would be more difficult for a renderer to perform this feat, particularly one that is designed as a real-time renderer, and therefore presumably has rather serious limitations on (...) (23 years ago, 12-Mar-04, to lugnet.cad.dev)

9 Messages in This Thread:



Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

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