FTP SITE FOR 3D OBJECT MODELS/UTILITIES

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Francisco X DeJes » Sun, 18 Oct 1992 02:33:54



Hello. It seems that there are always people here asking for information
on such sites, but there appear to be very little responses. Is there
any such site avaliable... a "central" site for 3D object models and
utilities?

If there isn't, we may just start one. We do a lot of work here using
Wavefront on SGI and HP machines, and already have a good number of objects
that we can make available for ftp. However, we don't want to have another
of the many sites out there with just a handful of files - that's the way
it is now and good stuff is scattered all over the net and is hard to track
down. So, if there is interest, we are willing to start up an anon ftp site
that will specialize in 3D graphics - object files (databases, libraries),
converters, utilities, textures... mostly for Wavefront but we'd be willing
to support others as well.

So... is there interest? Is there already such a site out there I don't know
about (so I don't have to waste my time doing this - instead, we'd be willing
to contribute what we have in order to centralize things)? Post, or respond by

OBdisclaimer: No promises or guarantees!
--

disclaimer: "Opinions expressed here are mine. Typos and errors are all yours."

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Tugrik d'Itic » Sun, 18 Oct 1992 08:29:54


Yes!  It sounds like a plan.  I've been sharing my IMAGINE! and SCULPT format
files with friends via local-networked bbs's (the C86kNet) for some time.  I
know that such files are not usually considered in the "class" that wavefront
and such object files are, but they are pretty detailed.

Could this site also include any PD/shareware/etc 3d datafile format converters
for swapping between platforms?  I may be naieve in suggesting this, as my
entire 3.5 years of computer animation experience has been only on the Amiga
platform (although I'd give vital organs for a day to play on a workstation
class machine)... but how about making such a FTP site where all objects are
converted to a Generic format, and you download a converter for your particular
renderer?  That way we can all share objects.

My 'specialty', if I were said to have one, in object design is quadrupedal
animal design in 3d; my best object is a decently cycle (Imagine! heirarchy)
oriented equine.

  -Tugrik

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Lance R. Marr » Sun, 18 Oct 1992 10:57:42


I would like to see it happen, yes!  I am not sure what my
employer would like me to help with (as far as what we have
to offer) but I could possibly add some objects, textures,
and/or converters to/from Wavefront.  ;>

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Lance R. Marrou


 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Bernie Roe » Tue, 20 Oct 1992 22:36:57



Quote:>how about making such a FTP site where all objects are
>converted to a Generic format, and you download a converter for your particular
>renderer?  That way we can all share objects.

Yes!  I think this is an excellent idea.  One question we should address is
what format to use.

I would suggest that whatever format we choose should be easily convertible to
other formats.  That probably means a polygon-based (i.e. faceted) format
rather than something more complex.

The requirement that it be convertible to other formats has several
implications.  (People who are unfamiliar with the various polygon-based
formats can feel free to skip the rest of this article).

The file should be plain ascii (though it'll probably be stored in a compressed
format of some sort).

It should support multi-sided convex planar polygons with no holes, and the
vertices be stored once and that the polygons reference them from there
(rather than storing vertices with the polygons).

"Why convex?  Why planar?"
    - These two are common requirements in most rendering systems.  It's
      certainly true that *some* systems can handle non-convex polygons;
      however, we want a format that's readily convertible to *anything* or
      the database will be of limited use.  Systems that can handle non-convex
      can certainly handle convex, but the reverse isn't always true.  And
      "convexifying" a non-convex polygon can be computationally expensive and
      doesn't always yield good results.

"Why multi-sided?  Why not just triangles?"
    - Because many systems *can* handles multi-sided polygons, and do so
      more efficiently than they do triangles.  There are also fewer rendering
      calls (so less overhead) and fewer recalculations of surface normals.
      Systems that only support triangles will have no problems, because it's
      trivial to break a convex poly into triangles.

"Why no holes?"
    - Because many rendering systems don't support them, and conversion of
      polys with holes (or inner loops) to simple polys is complex and often
      yields poor results.

"Why store the vertices separately?"
    - Because most objects share vertices among many polys, and it takes
      less space (on disk and in memory) to store them once rather than once
      for every polygon in which they occur.  It's trivial to convert to
      the other format for systems that need it, but combining vertices is
      tricky (how close to they have to be to be considered "the same"?)

"Why not store surface normals, and/or vertex normals?"
    - To save space (sort of like storing the vertices once).  The normals
      (if needed by the target format) can be computed easily during
      conversion, why take up the disk space storing them?

"What about vertex ordering in polys?  Clockwise or counter-clockwise?"
    - It's no big deal either way; most systems I've seen use
      counter-clockwise, so I'd say stick with that.

"What about surface colors?  And attributes, like reflectance?  And textures?"
    - I would say we should associate a surface name with each poly, and
      build up a "surfaces" database.  One could have as many properties
      associated with a surface as needed, but at the very least one should
      have the r,g,b color of the surface.  Other likely properties include
      diffuse and specular coefficients, phong exponent, transmissivity and
      index of refraction.  Possibly a surface texture name, and possibly
      an associated file for a texture map (or bump map, or what have you).

One format that looks pretty interesting is OFF.  There's already a TDDD2OFF
converter, for example, and OFF meets most of the requirements given above.
(The only one it doesn't support is named surfaces, and that strikes me
as a relatively simple extension).

Comments?

--
        Bernie Roehl, University of Waterloo Electrical Engineering Dept

        BangPath: uunet!watmath!sunee!broehl
        Voice:  (519) 885-1211 x 2607 [work]

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Darren Bur » Wed, 21 Oct 1992 08:43:28




>>how about making such a FTP site where all objects are
>>converted to a Generic format, and you download a converter for your particular
>>renderer?  That way we can all share objects.
>Yes!  I think this is an excellent idea.  One question we should address is
>what format to use.
>"Why store the vertices separately?"
>    - Because most objects share vertices among many polys, and it takes
>      less space (on disk and in memory) [...]
> [...]

This also makes it easier for wire-frame previewers.  Of course the emphasis
is on the renderers themselves.

Quote:>"Why not store surface normals, and/or vertex normals?"
>    - To save space (sort of like storing the vertices once).  The normals
>      (if needed by the target format) can be computed easily during
>      conversion, why take up the disk space storing them?

I agree that it's pointless to store a normal for a polygon, but I don't
think vertex normals can really be computed.  You don't know if a vertex
is part of a smoothly curved surface, or if the vertex is at a sharp edge
in the object.  I *think* OFF format only provides for normals of
polygons, though I could be wrong.  Somebody correct me if I am.

Quote:>"What about surface colors?  And attributes, like reflectance?  And textures?"
>    - I would say we should associate a surface name with each poly, and
>      build up a "surfaces" database.  [...]
> [...]

OFF provides color and various other surface characteristics, but I agree
that using a surface database is superior.  It makes it easy to quickly
change the surface of an object, if nothing else.

Quote:>One format that looks pretty interesting is OFF.  There's already a TDDD2OFF
>converter, for example, and OFF meets most of the requirements given above.
>(The only one it doesn't support is named surfaces, and that strikes me
>as a relatively simple extension).

I'd like to lend my support for OFF, too.  Of the several formats that I've
encountered to-date, I think it's the best.  At the risk of being non-standard,
it's very extendable (just add new keywords).  The suggestions made above
could be integrated into OFF with a minimum of effort.

Darren Burns

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Iva » Wed, 21 Oct 1992 12:18:15


I think a 'central' site would be an excellent idea - you may have trouble getting current updates from everyone though. Anyone else have thoughts?

        Ivan.

--
-----------------------------------------------------------------------------


248 Johnston St, Annandale |   UUCP       uunet!munnari!atlas.abccomp.oz!ivan

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Bernhard Geig » Wed, 21 Oct 1992 18:40:05



> "Why not store surface normals, and/or vertex normals?"
>     - To save space (sort of like storing the vertices once).  The normals
>       (if needed by the target format) can be computed easily during
>       conversion, why take up the disk space storing them?

I don't agree about vertex normals. Interpolating vertex normals is not
always trivial. Especially if you want to keep edges non-smooth in one
direction, and interpolated in the other. You may even have to duplicate
a subset of vertices, since vertex normals may be different in the same
vertex for adjacent polygons.

--------
Bernhard Geiger


2004, Route des Lucioles BP 93                 phone: +33 93 65 78 93
06902 Sophia Antipolis Cedex (France)          fax:   +33 93 65 76 43

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Bernie Roe » Thu, 22 Oct 1992 00:43:15



>I *think* OFF format only provides for normals of
>polygons, though I could be wrong.  Somebody correct me if I am.

The OFF file format doc I've got is dated October 1989; it does mention
vertex_normals as valid property name.

Quote:>OFF provides color and various other surface characteristics

Quite right; I hadn't looked at the OFF spec for a while when I posted.
It does support diffuse and specular coefficients, as well as specular
power.

Not sure if transmissivity and index of refraction are meaningful for
polygon reps.

So the only thing that's absent from OFF is some sort of texture mapping
capability.

Quote:>I'd like to lend my support for OFF, too.  Of the several formats that I've
>encountered to-date, I think it's the best.  At the risk of being non-standard,
>it's very extendable (just add new keywords).

Quite right; adding a "texture" property name would be easy enough to do.

Say, is there a more recent version of the OFF spec around anywhere?  Mine
is three years old this month.
--
        Bernie Roehl, University of Waterloo Electrical Engineering Dept

        BangPath: uunet!watmath!sunee!broehl
        Voice:  (519) 885-1211 x 2607 [work]

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Scott Ma » Thu, 22 Oct 1992 04:16:35



>"Why not store surface normals, and/or vertex normals?"
>    - To save space (sort of like storing the vertices once).  The normals
>      (if needed by the target format) can be computed easily during
>      conversion, why take up the disk space storing them?

I disagree with this.  There are times then I've got several polygons
joining at the same vertex, and some polygons use one value for the vertex
normal and some use another, depending on which "parts" are "joined" at that
vertex.

Scott Mark

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Eric Hain » Thu, 22 Oct 1992 23:04:10



>Yes!  I think this is an excellent idea.  One question we should address is
>what format to use.

Great post, and I hope something comes of it.  You bring up a lot of good
issues, and reasonable answers to most requirements you list.  As someone who
has spent a fair bit of time converting weird data formats from the net, I
thought I'd add my two cents.

Quote:>"Why not store surface normals, and/or vertex normals?"
>    - To save space (sort of like storing the vertices once).  The normals
>      (if needed by the target format) can be computed easily during
>      conversion, why take up the disk space storing them?

It's actually pretty hard to rebuild vertex normals if not available, at least
for non-trivial models.  For example, take a human head.  It looks rotten
without vertex normals, so you build up the connectivities into a list of
vertices and what polygons share each, then by whatever method you blend the
polygon normals to get a vertex normal.  Except there are places on the model
where the vertex is shared, but the vertex normal is different for the various
polygons.  For example, where the eyes meet the eyelids, where the teeth meet
the gums, where the lips meet the skin.  Some tricks can be done (like saying
"blend normals only if all normals are within X degrees of each other), but
you'll still get artifacts.  Much better to keep the normals per vertex around
if possible.

I agree that polygon normals are a waste to store.  Requiring the first three
vertices to be a convex angle on the surface would be nice (because then I
can cull - see next item).

Quote:>"What about vertex ordering in polys?  Clockwise or counter-clockwise?"
>    - It's no big deal either way; most systems I've seen use
>      counter-clockwise, so I'd say stick with that.

I honestly wish the models would have the same ordering to all polygons.
Things like TDDD have randomly ordered polygons.  If you've got rendering
system that uses only two-sided polygons, this is irrelevant, but in Starbase
and OpenGL, for example, there are front and back faces and it definitely
speeds up rendering if you can cull all backfacing polygons during rendering.

Other than that, I'm in full agreement with all your comments.

Eric

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by George Kyriaz » Sat, 24 Oct 1992 13:54:07




>>how about making such a FTP site where all objects are
>>converted to a Generic format, and you download a converter for your particular
>>renderer?  That way we can all share objects.

>Yes!  I think this is an excellent idea.  One question we should address is
>what format to use.

Provided that wuarchive has space (there are some space problems now), I
can archive models there.  

Quote:>I would suggest that whatever format we choose should be easily convertible to
>other formats.  That probably means a polygon-based (i.e. faceted) format
>rather than something more complex.

This is an interesting problem.  I think that at first iteration, you are
absolutely correct; we should use a format that is just polygons and don't
worry about more complex things.  As time progresses though (we've seen
that happening with CAD systems), you need to supply more structure.  A couple
of years ago it was almost inconcievable to assume that you average graphics
system was going to support NURBS, let alone trimmed NURBS.  Today almost
everybody has them.  Additionally I can give lots of reasons (upon request)
why you should use geometric primitives at least as complex as NURBS.
There are some cases where NURBS are not enough; you need more global
information.

I am not saying that we should use a complex format that includes NURBS,
superquadrics, cyclides or whatever you can grab from your neighborhood
Math department.  It would make a lot of sense though, to provide a data
format that is expandable, so that the standard can get easily extended.
Interestingly enough, object-oriented systems and databases provide this
expandability.  I don't have an answer though for creating an
object-oriented file format, though.  heh..

Quote:>"Why store the vertices separately?"
>    - Because most objects share vertices among many polys, and it takes
>      less space (on disk and in memory) to store them once rather than once
>      for every polygon in which they occur.  It's trivial to convert to
>      the other format for systems that need it, but combining vertices is
>      tricky (how close to they have to be to be considered "the same"?)

>"Why not store surface normals, and/or vertex normals?"
>    - To save space (sort of like storing the vertices once).  The normals
>      (if needed by the target format) can be computed easily during
>      conversion, why take up the disk space storing them?

Here, I will agree with Eric Haines (see appropriate article).  Certainly
facet normals only take up space, but vertex normals are sometimes
necessery.  This is interesting, since the vertex normal is not a property
of the 3-D point itself, but a property of the polygon that it belongs to.
So, are we going to keep shared points but not normals?  If you have
a different normal per-point and per-face, the memory required for normals
exceeds the memory required for the points themselves, so why share points?
My answer to this one is share points and normals/point, but if you
absolutely must have different normals for a certain point, you might as
well duplicate the point coordinates and specify the new normal with
the new point.

Quote:>"What about surface colors?  And attributes, like reflectance?  And textures?"
>    - I would say we should associate a surface name with each poly, and
>      build up a "surfaces" database.  One could have as many properties
>      associated with a surface as needed, but at the very least one should
>      have the r,g,b color of the surface.  Other likely properties include
>      diffuse and specular coefficients, phong exponent, transmissivity and
>      index of refraction.  Possibly a surface texture name, and possibly
>      an associated file for a texture map (or bump map, or what have you).

Agreed.  Additionally, all the graphics libraries that I've used
(GL,XGL,PHIGS), seem to support vertex colors in addition to global
polygon color.  They interpolate the vertex color and add it to the color
that you get when you perform lighting using normals.  The question is,
do we want to support vertex colors in the file format?

More comments?

  --george
--
----------------------------------------------------------------------------
George Kyriazis       | Visual Technologies Program, Rensselaer Design

----------------------------------------------------------------------------

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Bernie Roe » Mon, 26 Oct 1992 05:22:07



>>"Why not store surface normals, and/or vertex normals?"
>It's actually pretty hard to rebuild vertex normals if not available, at least
>for non-trivial models.

Yes, a number of people have pointed this out; fair enough, vertex normals
should be (optionally) included.  (If not included, they should just be
computed by the converter, assuming the target format needs them).

Quote:>>"What about vertex ordering in polys?  Clockwise or counter-clockwise?"
>I honestly wish the models would have the same ordering to all polygons.

Agreed!  Either the vertex ordering must be consistent, or polygon normals
must be provided (I prefer the consistent ordering approach, since it uses
no additional space).
 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Bernie Roe » Mon, 26 Oct 1992 05:48:56



>    Polygons!  We don't need no steekin' polygons!

I'm partial to polygons because they're simple, and everything seems to use
them.  Most existing file formats that I've seen are polygon-based -- haven't
seen too many that use patches.

Quote:>    Of course, I would suggest RIB, but hey, I am hardly unpartisan :-)
>    RIB may be complex, but it does address each of these problems.

Could you post the RIB spec?  If nothing else, it may give us some ideas.
 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Darren Bur » Mon, 26 Oct 1992 06:18:32




>>I would suggest that whatever format we choose should be easily convertible to
>>other formats.  That probably means a polygon-based (i.e. faceted) format
>>rather than something more complex.
>    AIIIGHHH!!!!!
>    Polygons!  We don't need no steekin' polygons!
>    Why are people so desparately afraid of patches?

Excuse my ignorance, but aren't patches just *sy polygons?  Everything
I've seen to date suggests that this is the case.

Quote:>    It basically makes your model useless at some
>    choice of viewpoint/scale.  Just say no!
>    One other thing.  Storing patches for curved surfaces means the files
>    are a LOT smaller.

If my understanding of patches is correct, then if you zoom in far enough
you'll see the individual patches.

Darren Burns

 
 
 

FTP SITE FOR 3D OBJECT MODELS/UTILITIES

Post by Mark W. Spychal » Mon, 26 Oct 1992 07:22:46


   I suggest that whatever standard format which is used for the 3D
object database be able to support some form of hierarchical description of
an object's construction.  Most objects consist of distinct parts with each
part having a list of properties (color, surface type description, etc..)
Having such a description of an object makes later modification of an object's
parts much easier.  With most objects I get currently from FTP sites on the
network I end up having to determine which polygons belong to which parts
myself if I want to modify the characteristics of a part.  Also, I prefer
objects described by sets of quadrics or by polygonal meshs instead of
straight polygons.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 
 
 

1. FTP SITE FOR 3D OBJECT MODELS/UTILITIES

  When it comes to a central database for 3D objects, everyone seems to be
considering only the shape of the object.  Even if polygon shapes were allowed
(such as used in POV-Ray, DKBTrace, etc.), we are still not considering
surface texture, reflectivity, specularity, etc.

  Also, the application of pictures as brush maps has not been considered, let
alone the colors of the individual polygons.  This will certainly not be a
trivial project.

  I do not think that .DXF would be the ideal format, but it may well be the
most useful.

--- Maximus 2.00

2. Looking for Animators

3. Any ftp sites for Wavefront object models?

4. problem building 3.7

5. 3D object models/utilities

6. REQ: Crazy person

7. FOLLOW-UP: FTP SITE FOR 3D MODELS/UTILS

8. Transparent images

9. FTP Site for 3D objects now OPEN!

10. Follow-up #2: FTP SITE FOR 3D MODELS...

11. MORE ON 3D MODEL FORMATS, FTP SITE, etc

12. ftp sites for 3D models

13. FTP sites for 3D objects