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 / 7248
7247  |  7249
Subject: 
Re: The use of type 5 lines for smoothing of objects.
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 20 May 2002 23:34:55 GMT
Viewed: 
455 times
  
In lugnet.cad.dev, Martijn Zwaal writes:
Looks good!!! Can you tell me which modifications you made?

I think I listed most of them, but here are the ones I can think of:

Calculated per part, not per dat file.

Only calculated when an edge is an exact match with a type 5 line; this
requires some extra work to accomplish.

Completely ignore the control points in the type 5 lines.

I don't normalize my normals along the way.  Once they are all added
together, I normalize the result.  This kind of gives heavier weighting to
larger polygons.  I realize that this isn't really how it works, but the
length of the cross product vector is related to the length of the two
vectors that it is calculated from, so leaving them un-normalized tends to
give more weight to bigger polygons.


I was able to reproduce the exact glitches you saw. They are due to round
off errors
in the coordinates. Your map sees a difference e.g. between point
(1.9999,0.0000,0.0000)  and point (2.0000,0.0000,0.0000) while these are the
same points in the model. You have to find a way to make the map search less
precise. I did it with a data type called TVertex that has this constructor:

I suspected that might be the case, but hadn't gotten around to checking.
My map is actually currently based on a string representation of the vector.
And, in my initial test, I'm using my own Map-type class, which I know not
to be very efficient.


My implementation is not very slow. That is because I load each dat file
only once and keep track of their pointers with a DatName2Pointer map. That
way I can link al data and save memory. I also do smoothing per dat file.You
can try the speed  by copying a lot of dat files in the testmodels map. They
are all loaded at the start of the program.

I do only process the part files once.  I later copy them for real-time
rendering performance reasons, but they only get processed once, and then
cached.  Since my smoothing is done at the part level, I have to re-smooth
all the primitives for each part, as well as any sub parts.  However, this
is the only way I can think of to get the smoothing to work across multiple
primitives in the same part.

As I mentioned above, I'm using a string representation of my vectors for my
key, and I'm using my own (known to be inefficient) Map-type class.  I
believe that my Map-type class is leading to n squared behavior.  Your idea
of using a scaled integer representation of the floating point numbers makes
a lot of sense from an efficiency standpoint.

--Travis Cobbs (tcobbs@REMOVE.halibut.com)



Message has 1 Reply:
  Re: The use of type 5 lines for smoothing of objects.
 
(...) If you ignore the type 5 control points, what points do you use to generate the cross products? I would think to generate "fair" lengthy vectors you'd have to use the center of gravity point for the adjacent quads or triangles. Otherwise you (...) (22 years ago, 21-May-02, to lugnet.cad.dev)

Message is in Reply To:
  Re: The use of type 5 lines for smoothing of objects.
 
(...) (with (...) the (...) helmet, (...) entirely (...) I was able to reproduce the exact glitches you saw. They are due to round off errors in the coordinates. Your map sees a difference e.g. between point (1.9999,0.0000,0.0000) and point (...) (22 years ago, 20-May-02, 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