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

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

Post by Francisco X DeJes » Thu, 22 Oct 1992 09:50:56



Well, the response we have gotten indicates there is great interest so at
this point it looks like it will probably be a go. Some clarifications as
to what we the contents of this ftp server will be:

      - What we want to have: 3D object files, supporting textures/maps/etc
        for those objects, and utilities to convert files between different
        3D file formats. 3D graphic demos and/or PD raytracers are already
        collected and available at other big sites, so I don't want to
        waste HD space by having duplicates of those.

      - Since we use Wavefront, that's our main file format for 3D
        objects (.obj files). We *do* want to support other file formats,
        so long as we can get a converter utility for them. For those
        who wish to contribute: if you have a model in a weird format,
        try to send us a utility that will convert it to something more
        common or at least a short text file describing this format.
        I'm particularly interested in DXF-to-anything and anything-to-DXF
        converters.

      - I'd also be interested in having any programs that can be useful
        to those making or viewing these models.

So, basically this will be a "repository" for objects and supporting files.
We'll probably expand on this as time goes by (and as our resources allow),
but for now, that's it. BTW, whatever file formats we carry, we're *NOT*
going to add to the chaos by creating a new one! I've seen several posts
regarding a format called "OFF" which sounds promising as a base-format.
Could someone please forward me some info on that?

Any comments/suggestions/opinions are more than welcome, as now would be
the best time for us to hear them! I'll be setting up the server and files
soon and will post again once the site is ready. In the meantime, start
digging up those cool models you have because everyone else wants to
see them too!

--

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

 
 
 

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

Post by Bernie Roe » Thu, 22 Oct 1992 22:36:47



Quote:>      - Since we use Wavefront, that's our main file format for 3D
>    objects (.obj files). We *do* want to support other file formats,
>    so long as we can get a converter utility for them.

Can you post the Wavefront file format?

Quote:>    if you have a model in a weird format,
>    try to send us a utility that will convert it to something more
>    common or at least a short text file describing this format.

I'd recommend using OFF.

Quote:>    I'm particularly interested in DXF-to-anything and anything-to-DXF
>    converters.

So am I!  I've been trying to get a DXF-reading library for some time, and
no one seems to have written one.

Quote:>I've seen several posts
>regarding a format called "OFF" which sounds promising as a base-format.
>Could someone please forward me some info on that?

We have a copy of the spec available for anonymous ftp from sunee.uwaterloo.ca,
in the pub/vr directory.  You should get off.ms.Z if you have access to Unix
troff, off.ps if you have a Postscript printer, or off.ps.Z if you have a
Postscript printer and access to the Unix "compress" program.

There may be a more recent version of the spec, but I haven't heard of one.
It's a nice, general, extensible format, and would seem to meet our needs.

--
        Bernie Roehl, University of Waterloo Electrical Engineering Dept

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

 
 
 

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

Post by Bob Steve » Fri, 23 Oct 1992 00:56:42


'm looking for papers, source code, or references to same on Canny Edge
Detectors.  Plz help!

Bob

 
 
 

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

Post by Mike Weisenbo » Sat, 24 Oct 1992 13:53:49



: but for now, that's it. BTW, whatever file formats we carry, we're *NOT*
: going to add to the chaos by creating a new one! I've seen several posts
: regarding a format called "OFF" which sounds promising as a base-format.

Although I like the idea of supporting a base format that could be used
as a universal to/from format with converters available as they are
written, I would like to discourage converting everything before it is
made available.  It would be nice to leave everything in its native
format and let people convert only if they need to.  Sometimes these
converters are not completely "lossless" so at least the people using
the original format could use the original object.

--
Mike Weisenborn              | Everything in this article is my opinion!

NASA Langley Research Center | Try Linux.

 
 
 

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

Post by Gerald Edg » Sat, 24 Oct 1992 00:43:04


May I suggest that as this effort is planned that thought be given to distribution
via CD-ROM? This would enable people without ready internet access to get the models.
it would also enable people to get at large numbers of models or large models without
impacting the host systems.
 
 
 

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

Post by Bernie Roe » Mon, 26 Oct 1992 05:41:39



>It would be nice to leave everything in its native
>format and let people convert only if they need to.

Perhaps, but...

Quote:>Sometimes these
>converters are not completely "lossless" so at least the people using
>the original format could use the original object.

What information is it that's getting lost, exactly?  If we store the
information we've discussed (including vertex normals where applicable)
then hopefully we won't be throwing away any information of consequence.

However, if we do decide there's more information in certain formats that
we want to retain, we might try a two-tier approach.  It seems to me that
all formats will either be equivalent to the standard, a subset, or a
superset.  With that in mind.

* Formats that are equivalent to or a subset of the "base" format be converted
  to the base format for storage in the archive; for these files, only one
  converter is needed to go to whatever format the user is using.

* Formats that are a superset of the "base" format should not be converted,
  but instead stored in their "native" format in the archive; for these, a
  converter to the "base" format would be provided.

The need for a "base" format exists in any case (to avoid having to have
N-squared conversion programs).

 
 
 

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

Post by Gavin Be » Mon, 26 Oct 1992 08:36:22


Quote:>What information is it that's getting lost, exactly?  If we store the
>information we've discussed (including vertex normals where applicable)
>then hopefully we won't be throwing away any information of consequence.

For starters, the object transformation hierarchy is important if you
want to do rigid-body animation of the objects.  OFF doesn't support
hierarchical objects.

The set of material properties supported is different for different
formats; how they can be applied varies (some allow only material per
object, some material per face, some material per vertex, etc.).

I like the two-tiered approach, but I think you'll have trouble
finding a 'base-level' format that is a superset of most other formats
and is also easy to convert to other formats.

The Iris Inventor format is a superset of just about every format I've
run across (RIB being the most notable exception).  However, I'm not
sure it would make a good 'base-level' format, since it is difficult
to support all of its features, and is difficult to write converters
to other formats.

I would actually like to see an OFF-like subset of the Inventor format
become the de-facto standard for polygonal data exchange.  Something
like:

#Standard 3D File Format V1.0
Coordinate3 {
        point [
                x y z,
                x y z,
... etc, all the coordinates.  The xyz values are just floating point
numbers.
        ]

Quote:}

Normal {
        vector [
                nx ny nz,
... etc, all the normals.
        ]
Quote:}

IndexedFaceSet {
        coordIndex [
                0, 1, 2, 3, -1, # First polygon
                1, 2, 14, -1,   # Second polygon
... etc, a list of indices for each polygon.  The indices index into
the Coordinate3 list defined above.
        ]
        normalIndex [
                0, 1, 2, 3, -1, # Normals for first polygon
... etc, a list of indices into the Normals defined above.  If
normalIndex has exactly one value of -1, or if normalIndex isn't
specified, normals will be used in the same order as the coordinates
(this is the common case of every vertex having exactly one normal).
        ]

Quote:}

--

 
 
 

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

Post by Stephen Pietrowi » Mon, 26 Oct 1992 23:10:27




]>It would be nice to leave everything in its native
]>format and let people convert only if they need to.
]
] Perhaps, but...
]
]>Sometimes these
]>converters are not completely "lossless" so at least the people using
]>the original format could use the original object.
]
] What information is it that's getting lost, exactly?  If we store the
] information we've discussed (including vertex normals where applicable)
] then hopefully we won't be throwing away any information of consequence.

Here's another vote to keep the objects in their original state.  Some
conversion programs toss away information because it doesn't convert well
to other formats.  (Surface names, surface subgroups, etc).   The *last*
thing we need is YAOF (Yet Another Object Format).
--
Where humor is concerned there are no standards -- no one can say what
is good or bad, although you can be sure that everyone will.
-- John Kenneth Galbraith

 
 
 

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

Post by Darren Bur » Tue, 27 Oct 1992 05:09:36



Quote:>Here's another vote to keep the objects in their original state.  Some
>conversion programs toss away information because it doesn't convert well
>to other formats.  (Surface names, surface subgroups, etc).   The *last*
>thing we need is YAOF (Yet Another Object Format).

True, even if we invent YAOF, it would have its shortfalls.  Basically,
you can't keep everyone happy at once -- no single format will suit
everyone's needs.

Keeping objects in their original state would mean an explosion of object
file formats.  The new FTP site would just be a single place where you
could get objects that are already available at various sites -- which is
good, but not great.

Perhaps what we need is to use a few formats (two or three).  OFF is fine
for my needs, but some people apparently want NURBS, object hierarchies,
surface names, etc.  We could have two or three supported formats, with
utilities on the same FTP site for converting one to another (where possible).
For example, there might be a NURBS object in some object format that supports
NURBS.  If somebody couldn't handle NURBS (like me), then they would download
the NURBS object and the NURBS-to-whatever converter.  Maybe, if there's
room, objects could be available in several formats.

Just a thought...
Darren Burns

 
 
 

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

Post by Matthew Kais » Wed, 28 Oct 1992 23:35:12


we might also consider raytracers with Constructive Solid Geometry (CSG)
i am in the works on building the NCC-1701-D for rayshade.4.0.6 using it's
object primitives which include CSG.

by the way, any one who can contact or give me an address for
Industrial Light & Magic (ILM), tell me who you are.

I'm going to make this database of the Enterprise-D the most extensive
on the network cloud (and i'm using a parallel supercomputer to do it!)

so i need the MOST detail plans anyone can get their hot little hands on
and help from ILM would be an Honored pleasure (even if they want'd some pics
from this, or whatever).

I have the basic shape, but i need things like shuttle craft, window placements
and the scribblings on the starship.


                                                        blackcat
hunter
guardian
explorer
predator
sentinel
student
romantic

 
 
 

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

Post by Mark Ko » Fri, 30 Oct 1992 01:31:03



>we might also consider raytracers with Constructive Solid Geometry (CSG)
>i am in the works on building the NCC-1701-D for rayshade.4.0.6 using it's
>object primitives which include CSG.

>I have the basic shape, but i need things like shuttle craft, window placements
>and the scribblings on the starship.



I just purchased the ST:TNG Technical Manual and it provides alot of information.
It should be available at any bookstore.

Mark

 
 
 

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

Post by Fernando Mato Mi » Fri, 30 Oct 1992 22:39:54




> Keeping objects in their original state would mean an explosion of
> object
> file formats.  The new FTP site would just be a single place where
> you
> could get objects that are already available at various sites -- which
> is
> good, but not great.

I would suggest that if the original version of a model is available
somewhere else, that only a highly compressed JPEG picture, commentary,
and the info on how to get it be kept on line. Of course, the site
owners could cache the models they consider convenient.

Somebody talked about having one directory per picture with all the
relevant data.
I think that's OK, if you also provide a complex (and redundant) link
network to
be able to access an object by different categories, as well as being
able to mget
complete pic or description directories without having to do it
individually.

Creating empty files of the form "node.name:/dir/subdir..." would enable
you to know where a pic is located just by 'ls'ing its directory (then
you can ftp with minimal effort if you have a cut buffer).

Whatever you decide, please bury GIFs. They are a waste of bandwidth,
disk space and color capabilities.

--
Fernando D. Mato Mira
Computer Graphics Lab
Swiss Federal Institute of Technology


FAX      : +41 (21) 693 - 5328

 
 
 

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

Post by Jerry Qui » Sat, 31 Oct 1992 02:28:13


The last time I played with OFF, it seemed to me that it was an
extensible format.  How about working on standard extensions to OFF
that allow NURBS and hierarchical objects.  It already has attached
file capabilites.  There is really only the issue of agreeing on new
standard fields and such.

Jerry Quinn

--
Jerry Quinn