Hi everyone & happy new year 2004
(not a true openGL question)

As gldrawarray() and other functions use U V texturing so what 3D file
format (& tools) do you use to import objects to your GL programs ? Maya
? Lightwave ? Imagine ? 3DS ? others ?

Is there a file format that got both UV texturing + Objects hierarchy +
Animation ?????

THANKS

> As gldrawarray() and other functions use U V texturing so what 3D
file
> format (& tools) do you use to import objects to your GL programs ?
Maya
> ? Lightwave ? Imagine ? 3DS ? others ?

Take what you think you will have at hand at most. So you don't have
to convert a lot before loading and using the object.

> Is there a file format that got both UV texturing + Objects
hierarchy +
> Animation ?????

3DS supports it, I'm not familiar with the others, but I think Maya
and Lightwave do, too. Load the object and keep the data in memory in
a form that is best/fastest for rendering. I load my objects in a
comressed form and then uncomress them when rendering. For static
objects I keep a glCompile - List with each object.

HTH,

-- 
-Gernot

Post here, don't email. If you feel you have to mail, revert my
forename from:
tonreG.Frisch.at.Dream-D-Sign.de@invalid.com
________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com

> As gldrawarray() and other functions use U V texturing so what 3D file
> format (& tools) do you use to import objects to your GL programs ? Maya
> ? Lightwave ? Imagine ? 3DS ? others ?
>
> Is there a file format that got both UV texturing + Objects hierarchy +
> Animation ?????

They all have defects related to 'realtime' rendering with latest
developments in the GPU end of the business. Some formats which otherwise
are decent have bloated to include a lot of information which you
don't -need- when doing GPU based rendering.

The best solution is to roll own fileformat and export to it using whatever
tools or export plug-ins you can develop for your favourite modelling
software. It's a bit of work, but it's not particularly difficult, atleast.
You will end up having precisely the features you need in the format. You
can also have the luxury of doing a lot of time-consuming pre-processing
before you write into the output stream.

Off-the-shelf software and their formats, little summary:

..3ds - crap
..lwo (version 4-6, crap)
..lwo (version 7+, only slightly crap :)
..max (useless, it's serialized format)
..asc - crap
maya ascii/binary formats: no idea, some helpful soul can help to fill in? I
heard that Maya SDK on Windows doesn't work with Visual C++ .NET 2003 - is
this true?

All the formats mentioned above don't store stuff you can preprocess and are
not particularly designed GPU's in mind, but rather to support the
feature-set of the packages the formats are mainly used with.

If I were to design a file-format from scratch now, some thoughts:

- it would be binary (sorry, no xml fanciness or similiar required for my
needs :)
- it would be chunky
- it would be based on "stream" / "channel" concept, for example, if I were
to save a vertex buffer/array, I would have unique channel for each
per-vertex attribute, advantage to storing array-of-struct is that
components which are not used are not stored, pretty obvious stuff..
- I would have a generic binary/id typing system so that I can use the same
code for reading+writing "virtual" channels
- material definition would store ascii shader sourcecode aswell (problem:
tied to particular high-level shading architechture)

Just from the top of my head. I would avoid hard-coding things as much as
possible, because when you have a flexible and generic framework you can let
the client to sort out what he needs from the 3d scene database and what he
doesn't.. also leave a lot of configuration headroom from exporting end of
the business so that exporter can only store what he needs the application
will use. I would use "profiles" for this in the exporter and easy one-click
way to change profile. Example: "symbian/mobile" vs. "playstation2" vs.
"directx 9.0" -profiles.

I don't mean hard-wired profiles, but just example what kind of profiles I
might have in my exporter. :) :) :)

Actually, if I realistically think about it, have spent a hell of a lot of
time + energy in maintaining the export/import database architechture. But
it's worth every hour I put at it, it pays back dividents in a long run.
Very, very glad didn't satisfy with a second-class ad-hoc solution for this.
I used to, years, years ago but then I was young and stupid. Now I am old
and stupid (but have learned a few lessons I wanted to share).

Good luck!

does anybody use blender? (...)



mario

John Smith a =E9crit :
> The best solution is to roll own fileformat and export to it using what=
ever
> tools or export plug-ins you can develop for your favourite modelling
> software. =

Yes it is what i do :
1) convert from maya with the "GE2 exporter" to text file
2) convert text files to c sources syntax
3) compile and save it in my own chuncked (IFF like) binary format
with points(with UV),faces,objects,hierarchy,frames,animation.

> heard that Maya SDK on Windows doesn't work with Visual C++ .NET 2003 -=
 is
> this true?
Dont know (i use LCC-Win32 or GCC on others platforms)

> - it would be binary (sorry, no xml fanciness or similiar required for =
my
> needs :)
DONE
> - it would be chunky
DONE
> - it would be based on "stream" / "channel" concept, for example, if I =
were
> to save a vertex buffer/array, I would have unique channel for each
> per-vertex attribute, advantage to storing array-of-struct is that
> components which are not used are not stored, pretty obvious stuff..
Not agree =3D better to allways save all (XYZ UV RGBA)
> - I would have a generic binary/id typing system so that I can use the =
same
> code for reading+writing "virtual" channels
DONE
> - material definition would store ascii shader sourcecode aswell (probl=
em:
> tied to particular high-level shading architechture)
not in my format
> I don't mean hard-wired profiles, but just example what kind of profile=
s I
> might have in my exporter. :) :) :)
intelligent way but i am doing only openGL
> Good luck!
THANKS