Hi - I'm trying to write a converter for Wavefront .OBJ file to uvPOV.
It's going quite well so far but... there are a few oddities to some
OBJ files which I've yet to find "the best" solution to.

For example.

Some .OBJ faces comprise more than 4 points. I've successfully tested
turning 4 points into 2 triangles, and this seems to work well. Does
anyone know how to reliably turn faces with more points into triangle
meshes? Or has anyone happened on a procedure which "happens to work"
(like my 1,2,3 - 3,4,1 procedure for 4-point faces)?

Other issues revolve around .OBJ files containing degenerate triangles
(sorted. Silly, but sorted) and having normals for only SOME of the
verteces of a triangle - at the moment I'm fudging this by using a
standard triangle (instead of a smooth triangle) for any triangle
which doesn't have a full set of normals.

Any help would be greatly appreciate :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Cliff Bowman wrote:
> 
> Hi - I'm trying to write a converter for Wavefront .OBJ file to uvPOV.
> It's going quite well so far but... there are a few oddities to some
> OBJ files which I've yet to find "the best" solution to.
> 
> For example.
> 
> Some .OBJ faces comprise more than 4 points. I've successfully tested
> turning 4 points into 2 triangles, and this seems to work well. Does
> anyone know how to reliably turn faces with more points into triangle
> meshes? Or has anyone happened on a procedure which "happens to work"
> (like my 1,2,3 - 3,4,1 procedure for 4-point faces)?
> 
> Other issues revolve around .OBJ files containing degenerate triangles
> (sorted. Silly, but sorted) and having normals for only SOME of the
> verteces of a triangle - at the moment I'm fudging this by using a
> standard triangle (instead of a smooth triangle) for any triangle
> which doesn't have a full set of normals.
> 
> Any help would be greatly appreciate :)
> 
> Cheers,
> 
> Cliff Bowman
> Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

I wonder if Thomas has had similar problems. I have noticed that when converting
some models with 3DWin that no matter what the smoothing angle specified there
are some times a few to several triangles that are still represented as simple
triangles instead of as smooth triangles.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Cliff Bowman wrote:
> 
> Some .OBJ faces comprise more than 4 points. I've successfully tested
> turning 4 points into 2 triangles, and this seems to work well. Does
> anyone know how to reliably turn faces with more points into triangle
> meshes? Or has anyone happened on a procedure which "happens to work"
> (like my 1,2,3 - 3,4,1 procedure for 4-point faces)?

Polygon triangulation is a pretty well-studied problem in computational
geometry.  Any textbook on computational geometry ought to have a
lengthy discussion of the topic.  Most of that is overkill, though.

If the polygons are convex, the simplest approach I know of is: 

-pick a point arbitrarily and call it 1
-number the rest of the points around the edge of the polygon as you did
previously, but keep going beyond 4
-divide the face up so it looks rather like a clamshell, with an edge
running from 1 to each of the other vertices
-triangles are <1,2,3>, <3,4,1>, <1, 4, 5>, <5, 6, 1> ...

If the polygons are not convex, recursively lop off pointy bits as
triangles until they are.  There's a bit of hand-waving there, but I'm
trying to wave my hand in the direction of the literature if you need
that kind of detail (not sure you do).

There are some efficiency concerns that are addressed in the literature,
but they are mostly of use to 2-D graphics, where polygons with large
numbers of vertices are used to approximate 2-D curves.  In 3-D
graphics, one seldom sees more N-gons with N>6 (except when the big 2-D
curve approximations get ducted, but that's an isolated case).

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Cliff Bowman wrote:
> 
> Hi - I'm trying to write a converter for Wavefront .OBJ file to uvPOV.
> It's going quite well so far but... there are a few oddities to some
> OBJ files which I've yet to find "the best" solution to.
> 
> For example.
> 
> Some .OBJ faces comprise more than 4 points. I've successfully tested
> turning 4 points into 2 triangles, and this seems to work well. Does
> anyone know how to reliably turn faces with more points into triangle
> meshes? Or has anyone happened on a procedure which "happens to work"
> (like my 1,2,3 - 3,4,1 procedure for 4-point faces)?
> 
> Other issues revolve around .OBJ files containing degenerate triangles
> (sorted. Silly, but sorted) and having normals for only SOME of the
> verteces of a triangle - at the moment I'm fudging this by using a
> standard triangle (instead of a smooth triangle) for any triangle
> which doesn't have a full set of normals.
> 
> Any help would be greatly appreciate :)
> 
> Cheers,
> 
> Cliff Bowman
> Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

I don't know if this'll alway work but I would calculate a 'middle'-point (M)
(adding up aal points in the object and dividing them by the amount of points)
then step through the row of points connecting two consecutive points to this M
(creating a triangle. 
Sounds like a fun experimenting thing...

Remco

Post a reply to this message

This will not always work if the polygon is not convex. M could end up outside
the polygon.

Margus

Remco de Korte wrote:
> 
> I don't know if this'll alway work but I would calculate a 'middle'-point (M)
> (adding up aal points in the object and dividing them by the amount of points)
> then step through the row of points connecting two consecutive points to this M
> (creating a triangle.
> Sounds like a fun experimenting thing...
> 
> Remco

Post a reply to this message

Remco de Korte wrote:
> 
> I don't know if this'll alway work but I would calculate a 'middle'-point (M)
> (adding up aal points in the object and dividing them by the amount of points)
> then step through the row of points connecting two consecutive points to this M
> (creating a triangle.

If the polygon is planar, there is no benefit to this approach.  If the
polygons are approximations of curved surfaces or the vertices are
points on a curved surface, picking a point in the middle and
reevaluating the surface function at that point does make some sense. 
If adding points isn't necessary, then adding points will increase the
number of triangles and thereby decrease performance.  If the polygon is
planar, just pick an existing vertex and draw edges to all the other
points. If all the narrow angles cause acne or something due to loss of
precision, though, your idea may be worth a shot.  I haven't actually
tried it.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Margus Ramst wrote:
> 
> This will not always work if the polygon is not convex. M could end up outside
> the polygon.
> 
> Margus
> 

I know, that's why I mentioned that I didn't know it will always work. By that I
didn't mean in general but in this particular situation. I was also assuming
that a polygone would be defined by points neatly arranged around the edge. In
the latter case I think you have a real problem. With a convex polygon the
solution is not very difficult but it'll result in even more triangles. 

Remco

Post a reply to this message

On Sat, 28 Aug 1999 18:41:55 -0700, Ken <tyl### [at] pacbellnet> wrote:

[snip]
>I wonder if Thomas has had similar problems. I have noticed that when converting
>some models with 3DWin that no matter what the smoothing angle specified there
>are some times a few to several triangles that are still represented as simple
>triangles instead of as smooth triangles.
>
>-- 
It wouldn't surprise me. I'm finding that the contents of .OBJ files
are, at times, incredibly erm... disorganised.

BTW check your e-mail :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Sun, 29 Aug 1999 09:18:52 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>Remco de Korte wrote:
>> 
>> I don't know if this'll alway work but I would calculate a 'middle'-point (M)
>> (adding up aal points in the object and dividing them by the amount of points)
>> then step through the row of points connecting two consecutive points to this M
>> (creating a triangle.
>
>If the polygon is planar, there is no benefit to this approach.  If the
>polygons are approximations of curved surfaces or the vertices are
>points on a curved surface, picking a point in the middle and
>reevaluating the surface function at that point does make some sense. 
>If adding points isn't necessary, then adding points will increase the
>number of triangles and thereby decrease performance.  If the polygon is
>planar, just pick an existing vertex and draw edges to all the other
>points. If all the narrow angles cause acne or something due to loss of
>precision, though, your idea may be worth a shot.  I haven't actually
>tried it.
>
I think what I'm going to ahve to do is write a "face preview"
facility in OBJuvPOV I think. So that I can *see* what the program's
encountering to help me evaluate which tack might work (I'm not good
at math - I've not the first idea how to work out if a face is planar
given just the verteces - unless they happen to lie along one of the
axes, of course!).


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Cliff Bowman wrote:
> 

> I think what I'm going to ahve to do is write a "face preview"
> facility in OBJuvPOV I think. So that I can *see* what the program's
> encountering to help me evaluate which tack might work (I'm not good
> at math - I've not the first idea how to work out if a face is planar
> given just the verteces - unless they happen to lie along one of the
> axes, of course!).

Any three points define a plane.  Derive an equation of that plane from
the vertices, and test the other points to see whether they lie on that
plane.  Actually, you should expect a little deviation from the plane on
account of finite precision, so test whether the point is within some
small distance epsilon of the plane.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote:
: If the polygons are not convex, recursively lop off pointy bits as
: triangles until they are.

  If you take any three points of the polygon, how can you be sure that
the triangle defined by them is completely inside the polygon?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Mark Gordon <mtg### [at] mailbagcom> wrote:
> : If the polygons are not convex, recursively lop off pointy bits as
> : triangles until they are.
> 
>   If you take any three points of the polygon, how can you be sure that
> the triangle defined by them is completely inside the polygon?

I made implicit reference to a "pointy bit test" ... yeah, that's right.
;-)

Assume the polygon is defined as a sequence of points on its periphery. 
A triplet of points on the edge of the polygon forms a "pointy bit" (my
jargon) if the interior angle formed at the second point (as measured in
the plane defined by the three points) is less than 180 degrees.  If the
interior angle formed at the second point is greater than 180 degrees
it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
well remove the middle point as redundant.

Conversion to radians is left as an exercise for the reader. ;-)

Pardon me for being a bit punchy - didn't get much sleep.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

On Mon, 30 Aug 1999 07:52:45 -0500, Mark Gordon wrote:
>Nieminen Juha wrote:
>> 
>> Mark Gordon <mtg### [at] mailbagcom> wrote:
>> : If the polygons are not convex, recursively lop off pointy bits as
>> : triangles until they are.
>> 
>>   If you take any three points of the polygon, how can you be sure that
>> the triangle defined by them is completely inside the polygon?
>
>I made implicit reference to a "pointy bit test" ... yeah, that's right.
>;-)
>
>Assume the polygon is defined as a sequence of points on its periphery. 
>A triplet of points on the edge of the polygon forms a "pointy bit" (my
>jargon) if the interior angle formed at the second point (as measured in
>the plane defined by the three points) is less than 180 degrees.  If the
>interior angle formed at the second point is greater than 180 degrees
>it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
>well remove the middle point as redundant.

Unfortunately, it's not quite that easy.  You can't lop of just any
pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
the center of the base.  Move that vertex upward, so what you get looks
like a rather angular version of the Federation emblem from Star Trek.
Note that the angle surrounding the topmost vertex qualifies as a 
"pointy bit" yet the resulting triangle is neither inside nor outside
the polygon.

Post a reply to this message

Mark Gordon <mtg### [at] mailbagcom> wrote:
: Assume the polygon is defined as a sequence of points on its periphery. 
: A triplet of points on the edge of the polygon forms a "pointy bit" (my
: jargon) if the interior angle formed at the second point (as measured in
: the plane defined by the three points) is less than 180 degrees.  If the
: interior angle formed at the second point is greater than 180 degrees
: it's an, um, "anti-pointy bit". :-)  If it's exactly 180, you may as
: well remove the middle point as redundant.

  This doesn't work. A vertex of the polygon may lie inside the triangle.
If this is so, the triangle will be partially outside the polygon.
  Think about an 'L' made of 6 vertices. Now take the upper left vertex,
the lower left vertex and the lower right vertex. The triangle they define
"seems" to be inside the polygon, but it doesn't.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ron Parker wrote:
> 
> Unfortunately, it's not quite that easy.  You can't lop of just any
> pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
> the center of the base.  Move that vertex upward, so what you get looks
> like a rather angular version of the Federation emblem from Star Trek.
> Note that the angle surrounding the topmost vertex qualifies as a
> "pointy bit" yet the resulting triangle is neither inside nor outside
> the polygon.

Point well taken.  Like I said, I was a bit sleep deprived.

-- 
Mark Gordon
mtg### [at] povrayorg

Post a reply to this message

Hi,

>I wonder if Thomas has had similar problems. I have noticed that when converting
>some models with 3DWin that no matter what the smoothing angle specified there
>are some times a few to several triangles that are still represented as simple
>triangles instead of as smooth triangles.

Hmm, current 3DWin import of OBJ files is very simple. It processes
only face information (no normals or uv faces). Smoothing is done in a
seperate stage. 

I have found and tested some very strange OBJ files with missing
vertices, wrong face to vertex links, double faces and lots of
degenerated faces.

3DWin tries to fix this errors and throws out such faces.

-Thomas

Post a reply to this message

On Wed, 01 Sep 1999 06:11:34 GMT, NOS### [at] ibmnet (Thomas
Baier) wrote:

[snip]
>I have found and tested some very strange OBJ files with missing
>vertices, wrong face to vertex links, double faces and lots of
>degenerated faces.
>
>3DWin tries to fix this errors and throws out such faces.
>
OBJ files do seem to be annoyingly... poorly written, don't they?
Degenerate faces is the first problem that surprised me (closely
followed by faces with 26 verteces - which I think I've now sussed).
the number of degenerate faces the average .OBJ contains is almost
depressing.

Double faces I think I know the reason for. A lot of modellers seem to
get the normals *wrong* and so users sometimes make a copy of the
model, flip the normals, and combine the two sets of meshes.

Dirty, and probably works in many cases (i.e. patches holes) but time
and memory are both wasted. I can't help but feel it'd cause some
renderers to cough and splutter too  - though as I've not knowingly
come across this yet I don't know how much POV "likes" or dislikes it.

I'd expect there to be "coincident faces" (is that the term?) problems
though.


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Tue, 31 Aug 1999 21:17:41 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>Ron Parker wrote:
>> 
>> Unfortunately, it's not quite that easy.  You can't lop of just any
>> pointy bit.  Take a simple isosceles triangle.  Add a new vertex at
>> the center of the base.  Move that vertex upward, so what you get looks
>> like a rather angular version of the Federation emblem from Star Trek.
>> Note that the angle surrounding the topmost vertex qualifies as a
>> "pointy bit" yet the resulting triangle is neither inside nor outside
>> the polygon.
>
>Point well taken.  Like I said, I was a bit sleep deprived.
>

It would appear from empiracle evidence that .OBJ writers are using
the many-verteces face as a space saving technique (obviously 20-odd
coplanar triangles take less file space when expressed as a single
face than as numerous triangles). I have yet to find a face which
isn't convex, or one that isn't co-planar. As such I've got a simple
solution in place just waiting for a .OBJ file with the right
deficiencies to make the program translate incorrectly <eg>

Please - no one build a .OBJ in a text editor just to break the
program!


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Wed, 01 Sep 1999 23:45:37 GMT, c.b### [at] cwcomnet (Cliff Bowman)
wrote:

>On Wed, 01 Sep 1999 06:11:34 GMT, NOS### [at] ibmnet (Thomas
>Baier) wrote:
>
>
>Double faces I think I know the reason for. A lot of modellers seem to
>get the normals *wrong* and so users sometimes make a copy of the
>model, flip the normals, and combine the two sets of meshes.

Right.

>
>Dirty, and probably works in many cases (i.e. patches holes) but time
>and memory are both wasted. I can't help but feel it'd cause some
>renderers to cough and splutter too  - though as I've not knowingly
>come across this yet I don't know how much POV "likes" or dislikes it.
>
>I'd expect there to be "coincident faces" (is that the term?) problems
>though.

I'm not really sure what you mean.

But one of the problems is that bordering faces do not use same the
vertices.

Anyway, you have to go around all problems to make a robust converter.

You have to build in some checks, which make the import slower.

-tb

Post a reply to this message

On Wed, 01 Sep 1999 23:45:37 GMT, Cliff Bowman wrote:

>Double faces I think I know the reason for. A lot of modellers seem to
>get the normals *wrong* and so users sometimes make a copy of the
>model, flip the normals, and combine the two sets of meshes.

I've actually seen this approach RECOMMENDED in an otherwise good
book.  Might have had something to do with the book being written
for an inferior modeller like MAX, though... <big grin for Lance>

Post a reply to this message

On 2 Sep 1999 09:22:17 -0400, par### [at] fwicom (Ron Parker) wrote:

>On Wed, 01 Sep 1999 23:45:37 GMT, Cliff Bowman wrote:
>
>>Double faces I think I know the reason for. A lot of modellers seem to
>>get the normals *wrong* and so users sometimes make a copy of the
>>model, flip the normals, and combine the two sets of meshes.
>
>I've actually seen this approach RECOMMENDED in an otherwise good
>book.  Might have had something to do with the book being written
>for an inferior modeller like MAX, though... <big grin for Lance>


????

Good grief.

And I'd just been working from conjecture... if such double faces WERE
imported into POV, how would it cope I wonder? I'll have to give it a
try. I can't help but think that with 2 triangles at the same point
POv would have difficulty deciding on which one to render at any given
X-Y co-ordinate - sometimes picking the one with the "correct" normal
and sometimes picking the other...



Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Thu, 02 Sep 1999 07:01:36 GMT, NOS### [at] ibmnet (Thomas
Baier) wrote:

>On Wed, 01 Sep 1999 23:45:37 GMT, c.b### [at] cwcomnet (Cliff Bowman)
>wrote:
[snip]
>>I'd expect there to be "coincident faces" (is that the term?) problems
>>though.
>
>I'm not really sure what you mean.

If 2 faces using the same vertecices, but with flipped normals (to
avoid holes) were imported, I wonder if POV would suffer from it's
co-incident faces problem. Like I've seen it (admittedly in the past)
where two objects are unioned instead of merged and have x,y, and z
co-ordinates equal at some point(s) - let's say one red cube and one
blue one.

box <-1,-1,-1>,<0.5,0.5,1> RED
box <-0.5,-1,-1><1,1,1> BLUE

For any given point where the faces are identically positionsed (X >=
-0.5 and X <= 0.5) should POV render red or blue?

Poor wording but then I don't write well.

>But one of the problems is that bordering faces do not use same the
>vertices.

Argh. That could be a problem - bordering faces not using the same
vertices? I'll have to watch for that.

>Anyway, you have to go around all problems to make a robust converter.
>
>You have to build in some checks, which make the import slower.
>
Speed fortunately isn't my main concern :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

On Fri, 03 Sep 1999 21:20:21 GMT, Cliff Bowman wrote:
>And I'd just been working from conjecture... if such double faces WERE
>imported into POV, how would it cope I wonder? I'll have to give it a
>try. I can't help but think that with 2 triangles at the same point
>POv would have difficulty deciding on which one to render at any given
>X-Y co-ordinate - sometimes picking the one with the "correct" normal
>and sometimes picking the other...

It'd probably still work.  POV tends to flip the normal to the "correct"
orientation anyway, so both triangles would be essentially identical and
it wouldn't matter which of the two you hit.

Post a reply to this message

On 3 Sep 1999 17:29:39 -0400, par### [at] fwicom (Ron Parker) wrote:

>On Fri, 03 Sep 1999 21:20:21 GMT, Cliff Bowman wrote:
>>And I'd just been working from conjecture... if such double faces WERE
>>imported into POV, how would it cope I wonder? I'll have to give it a
>>try. I can't help but think that with 2 triangles at the same point
>>POv would have difficulty deciding on which one to render at any given
>>X-Y co-ordinate - sometimes picking the one with the "correct" normal
>>and sometimes picking the other...
>
>It'd probably still work.  POV tends to flip the normal to the "correct"
>orientation anyway, so both triangles would be essentially identical and
>it wouldn't matter which of the two you hit.

I've seen some pretty ugly, gappy .OBJ files imported with other tools
(OBJ2POV IIRC) where the triangles didn't get flipped - which is one
reason I've found announcements like SSS interesting. Figuring a way
to calculate normals for point son a mesh and comparing them to the
original to see if it's pointing the wrong way is something I'd like
to try (later). I'd rather not just recalculate normals in case there
are .OBJ files which actually *use* the normals they supply (for
bumps, dents, etc.).

I've got a good example of an OBJ file with many correct and many
incorrect normals. 3D Win seeems to do a good job of correcting those
facets when it exports to POV, but sadly not when it exports back to
OBJ format (no idea why).

I did try using the OpenGL version of 3D Win to see what it was
holding internally after importing an OBJ, but I can't get it not to
crash my PC :(

So - examining SSS and learning how to calculate normals seems like a
way to go :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

>I've got a good example of an OBJ file with many correct and many
>incorrect normals. 3D Win seeems to do a good job of correcting those
>facets when it exports to POV, but sadly not when it exports back to
>OBJ format (no idea why).
Hmm, be sure,  if you import a file, that the "unify" option is
switched on.

>
>I did try using the OpenGL version of 3D Win to see what it was
>holding internally after importing an OBJ, but I can't get it not to
>crash my PC :(
HW or SW OpenGL ?

Thomas

Post a reply to this message

On Mon, 06 Sep 1999 04:52:48 GMT, NOS### [at] ibmnet (Thomas
Baier) wrote:

>>I've got a good example of an OBJ file with many correct and many
>>incorrect normals. 3D Win seeems to do a good job of correcting those
>>facets when it exports to POV, but sadly not when it exports back to
>>OBJ format (no idea why).
>Hmm, be sure,  if you import a file, that the "unify" option is
>switched on.

Hmm.. tried that just now (while reading your message) and it hasn't
noticably helped - the .OBJ is still full of holes. Personally I blame
the modelling software for getting it wrong in the first place. You're
welcom to a copy of the Rex .OBJ file if you want to play with it
(although it's about 1.2MB unzipped).

>>
>>I did try using the OpenGL version of 3D Win to see what it was
>>holding internally after importing an OBJ, but I can't get it not to
>>crash my PC :(
>HW or SW OpenGL ?
>
Hardware - it's a TNT board made by Diamond. Let me check... Viper
V550 running under Windows98 SE, 96MB RAM, P 233 MMX (yes not even a
Pentium II) and far, far too much software on the hard drives :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Hi,
>
>Hmm.. tried that just now (while reading your message) and it hasn't
>noticably helped - the .OBJ is still full of holes. Personally I blame
>the modelling software for getting it wrong in the first place. You're
>welcom to a copy of the Rex .OBJ file if you want to play with it
>(although it's about 1.2MB unzipped).
It would be nice to send me the TRex file. Perhaps i find some bugs
:_)

>
>>>
>>>I did try using the OpenGL version of 3D Win to see what it was
>>>holding internally after importing an OBJ, but I can't get it not to
>>>crash my PC :(
>>HW or SW OpenGL ?
>>
>Hardware - it's a TNT board made by Diamond. Let me check... Viper
>V550 running under Windows98 SE, 96MB RAM, P 233 MMX (yes not even a
>Pentium II) and far, far too much software on the hard drives :)
Hmm, i have tested 3DWinOGL with several GFX boards (but not TNT) .
Are you sure, that TNT renders into a window?

-tb

Post a reply to this message

On Wed, 08 Sep 1999 04:24:22 GMT, NOS### [at] ibmnet (Thomas
Baier) wrote:

>Hi,
>>
>>Hmm.. tried that just now (while reading your message) and it hasn't
>>noticably helped - the .OBJ is still full of holes. Personally I blame
>>the modelling software for getting it wrong in the first place. You're
>>welcom to a copy of the Rex .OBJ file if you want to play with it
>>(although it's about 1.2MB unzipped).
>It would be nice to send me the TRex file. Perhaps i find some bugs
>:_)

Always a possibility but I find it annoying, to say the least, to have
to write around other people's bugs. Why can't modelling programs "get
it right" in the first place? Then there'd be no need for these
shinnanegans...

Still, I'll e-mail a simple Rex .OBJ off to you (not the final quality
one I'd like to use, because that's big - but the one I've been using
for testing).

>>>>
>>>>I did try using the OpenGL version of 3D Win to see what it was
>>>>holding internally after importing an OBJ, but I can't get it not to
>>>>crash my PC :(
>>>HW or SW OpenGL ?
>>>
>>Hardware - it's a TNT board made by Diamond. Let me check... Viper
>>V550 running under Windows98 SE, 96MB RAM, P 233 MMX (yes not even a
>>Pentium II) and far, far too much software on the hard drives :)
>Hmm, i have tested 3DWinOGL with several GFX boards (but not TNT) .
>Are you sure, that TNT renders into a window?
>
Yup - sPatch, Unreal, 3D Labs X29 (an OpenGL "test" utility) all
render in a window (although Unreal's OpenGL seems decidely slow at
present - something they plan to address, I hear). Most other stuff I
tend to use fullscreen (actualy Unreal is Usually full screen but
they've got some bugs at the moment with D3D / TNT usage which makes
switching between windowed and full screen unreliable - no other App I
use has this problem - but their TNT D3D is still better than their
OpenGL support IMO).


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message