importing models

How can I import polygonal models (3ds, obj) into Croquet? Is a non-scripted
based, mesh importing mechanism implemented already in CC?

Thank you,

haggai

I should probably add to this question - if the way to do it right now is with
ThreeDSParser class - Where can I find the class and how can I use it?

Thank you

haggai

The quick "user" answer for the KAT demo: Just drag  an .ase file  
from your desktop into a running KAT demo.  You can also use New-
 >From File...
Use whatever external tool you like to get your mesh into .ase  
format, as you only do this once.  (Creating and importing a mesh  
isn't a daily end-user occurrence.)

Note: other demos support other formats. In particular, SimpleDemo  
supports .obj for Avatars.

For the longer "developer" answer, there are three things to think  
about:

1. How do you want to represent the result within Croquet?  Almost  
certainly, what you're thinking of so far can be implemented using  
the TMesh class. But there's nothing magic about this. You might want  
to create your own subclass of TMesh to handle additional  
capabilities, or maybe some other representation altogether.  You  
also might want to embed the mesh within some container class.  As it  
happens, the KAT code embeds meshes (and nearly every other 3D  
object) within KMedia3DContainer, which provides standard behavior  
for context menus, 3D buttons to "grab" or open an "editor", etc.

2. How do you parse a file and generate a mesh (or instance of  
another object)?  Croquet has long provided TLoad3DSMax for  
handling .ase files.  There is also TLoadMDL for a file format used  
by the Squeak Wonderland project (and no one else), but which  
provides the avatars and other furnishings for a lot of the demos.  
OBJImporter handles .obj files. The VRML package in the Contrib  
repository (not pre-loaded in the CroquetCollaborative distribution)  
provides the VRMLCroquetBuilder to handle .vrml/.wrl files.

3. Should an end-user be able to invoke anything from (2) to create  
the stuff in (1), or should it be only programmers? What user  
interface should an end-user have?

Each demo/application faces the same issues, but each has different  
objectives and therefore different details in how these are handled.  
For example, VRMLDemoMaster is only meant to show that a .wrl file  
can be used, and it hard codes a specific file (which isn't actually  
provided).  It provides no end-user UI for importing.  In the KAT  
demo, both UIs (file-pick or drag-and-drop) end up going through the  
same parsing method, which currently handles only .ase and .mdl. Look  
at the #parse: class method of KMediaMesh, and (he says sheepishly,)  
the #mediaClassFor: class method of KMedia. These two places  (should  
be just just one) are where you would hook in a new parser so that it  
works like everything else in the KAT demo. For example, after  
#parse:, the result will get wrapped in KMedia3DContainer.  Extending  
these to handle .obj and .vrml is an excellent exercise left to the  
reader (as we used to say in school).  (You might need to also look  
at KStandardHarness>>promptForStream.)

As to how you find a class or method, and how you modify it, see  
http://opencroquet.org/index.php/Tutorials#Learning_Squeak

-H

On Mar 13, 2007, at 5:12 PM, haggai wrote:

Hi Howard

|The quick "user" answer for the KAT demo: Just drag  an .ase file  
|from your desktop into a running KAT demo.  You can also use New-
|>From File...

If you don't mind I will make some comments from a user's POV. I think I'm a
few light years away from being a developer on croquet:

|Use whatever external tool you like to get your mesh into .ase  
|format, as you only do this once.  (Creating and importing a mesh  
|isn't a daily end-user occurrence.)

Actually i'm willing to testify that importing meshes is extremely iterative
process. Typically several departments ('end-users' such as modeling dept.
rigging dept. rough-layout dept. etc; ) will "communicate" models and textures
between them. The entire digital pipeline is highly dependent on this being as
transparent as much as possible. But even if this is just a solo-artist working
at home, he/she will most likely will have many repetitions to fine-tune the
set/environment/characters/textures/props before happy with it, etc;

Your drag and drap (and 'from file') mechanism is very elegant way to work,
only it should be consistent to include the main industry "standard" formats.
the generality of command 'from file' actually suggests to the user that any
file format is acceptable. That makes a lot of sense if we follow this
"transparency" logic.

|Note: other demos support other formats. In particular, SimpleDemo  
|supports .obj for Avatars.

I think I am not the only one saying this by now - we became too much fans of
KAT (CC) and won't likely to bother too much with the other demos by now.

|For the longer "developer" answer, there are three things to think  
|about:

|1. How do you want to represent the result within Croquet?  Almost

The result should be:

a. The meshes imported with no changes in matrix transformation: scaling,
translation, rotation and hierarchical relationships should stay intact as it
was at the source 3d modeling software. The reason is  that if you try to
import a whole set you may sometimes want to replace only certain element so
you would expect things to just fall into place. for example: a room with a
table in the center, a vase on the table, flowers in the vase, 4 chairs around
the table. - If I only change the flowers and one chair (because it went to
"dailies" and the director didn't like it) I want the flowers back in the vase,
and the chair where it was...
So what I am getting at - this is an important asset management issue.

b. Materials and textures should remain as-is. We should assume that designers
have spent a lot of rendering time already trying to get to the desired result.
If we have to start from scratch here, we gain nothing. Mostly what I am
referring to here is the issue of texture mapping. From the few tests I ran,
and I hope I am wrong, I think there isn't yet a connection between the source
texture maps and what is created in croquet. Croquet needs to identify on the
imported object: "This is a spherical mapping, so I must map it the same way,
etc;"

I can't stress enough how important these two issues are. If we ever want to
get a functional and sustainable work-flow we need to get this right!

(Notice I left animation out of this for now. We are certainly not there yet!)
 
 
|certainly, what you're thinking of so far can be implemented using  
|the TMesh class. But there's nothing magic about this. You might want
|to create your own subclass of TMesh to handle additional  
|capabilities, or maybe some other representation altogether.  You  
|also might want to embed the mesh within some container class.  As it
|happens, the KAT code embeds meshes (and nearly every other 3D  
|object) within KMedia3DContainer, which provides standard behavior  
|for context menus, 3D buttons to "grab" or open an "editor", etc.

|2. How do you parse a file and generate a mesh (or instance of  
|another object)?  Croquet has long provided TLoad3DSMax for  
|handling .ase files.  There is also TLoadMDL for a file format used  
|by the Squeak Wonderland project (and no one else), but which
|provides the avatars and other furnishings for a lot of the demos.  
|OBJImporter handles .obj files. The VRML package in the Contrib  
|repository (not pre-loaded in the CroquetCollaborative distribution)  
|provides the VRMLCroquetBuilder to handle .vrml/.wrl files.

From the little I can understand from what you are saying here everything that
we need for good importing is already there - only it needs a better interface!

|3. Should an end-user be able to invoke anything from (2) to create  
|the stuff in (1), or should it be only programmers? What user
|interface should an end-user have?

The worst mistake we can do is design the software unaccessible at some level
to the users. separating between users and developers is a separate discussion,
but let's take one example: Maya. By far one of the best 'non-proprietary'
software out there. Great deal of work was done to provide two (not one)
scripting languages engines to the users. Users (rigger, modelers, lighters,
texturers, etc;) In addition to manipulating objects from the GUIs, users are
able to program what they need to, That is: the objects themselves, without
having to worry about the lower level code of the 3d software itself. This
concept is crucial to understand: scripting is only secondary in the sense that
it should come later. You would want to first rapid-prototype as much as
possible using GUI manipulators, then continue with procedural scripting to
automate processes wherever you can.

Oh, well I got slightly carried away here -

back to my original point:  maya was always annoying on a few basic things,
probably the worst was: insufficient and inconvenient access to the matrices
(and the math)    
(I will leave the right way of doing this to a separate discussion)
The point is - users such as riggers still have to struggle with enormous
unnecessary complexity to get the simplest things done. Only because they never
had true access to the 'lego building blocks' or 'atoms', or 'primitives'.  

|Each demo/application faces the same issues, but each has different  
|objectives and therefore different details in how these are handled.  
|For example, VRMLDemoMaster is only meant to show that a .wrl file  
|can be used, and it hard codes a specific file (which isn't actually  
|provided).  It provides no end-user UI for importing. In the KAT  
|demo, both UIs (file-pick or drag-and-drop) end up going through the  
|same parsing method, which currently handles only .ase and .mdl.

Which is right, and in the right direction!

|Look  
|at the #parse: class method of KMediaMesh, and (he says sheepishly,)  
|the #mediaClassFor: class method of KMedia. These two places  (should
|be just just one) are where you would hook in a new parser so that it
|works like everything else in the KAT demo. For example, after  
|#parse:, the result will get wrapped in KMedia3DContainer.  Extending
|these to handle .obj and .vrml is an excellent exercise left to the  
|reader (as we used to say in school).

That's funny. I think you mean an advanced reader. not me...
Someone will have to write on my grave: "killed by a learning curve"

|(You might need to also look  
|at KStandardHarness>>promptForStream.)

|As to how you find a class or method, and how you modify it, see  
|http://opencroquet.org/index.php/Tutorials#Learning_Squeak

Thank you!

haggai

Anyone knows of a 3DS to ASI (binary to ascii) converter? (besides "Polytrans")
that is very expensive)

h

Great feedback. Thanks!

haggai wrote:
Good point.

>
> Your drag and drap (and 'from file') mechanism is very elegant way to work,
> only it should be consistent to include the main industry "standard" formats.
> the generality of command 'from file' actually suggests to the user that any
> file format is acceptable. That makes a lot of sense if we follow this
> "transparency" logic.

Right. For most obvious non-prototype/non-demo uses of KAT, you would want the
user to just not have to worry about format. The standard stuff should all "just
work", and anything else should be handled with no more than a pause as the
machinery goes off to find and install an appropriate plugin.  I agree.

This is interesting. I hadn't thought of this.

My thinking was that importing external stuff into Croquet should stick it in
front of you, so that you can see it and then interactively move/rotate/scale it
to wherever else it belongs.  When I tell someone to "hand me that wrench," I
don't want them to stand there next to the toolbox. I want them to hold it under
the damn car so I can grab the thing.

I think this is a good model for casual users, and I'm loathe to give it up or
introduce multiple "modes" for importing. But you do make a good point in that
sometimes you need to be able to quickly bring stuff in to the location
specified by the external designer.

Maybe there's a way to accomplish both ways of working? Instead of choosing to
reposition or not reposition the imported object, suppose we repositioned
ourself?  For example, we could have a content menu item to position the avatar
at just the right location relative to the selected object so that importing a
new object will be aligned with the same coordinate system.  We already have the
"bring me to this object" 3D down-arrow button. We would just have to make this
consistent with the positioning used when importing.  I love being able to
accomplish more stuff without expanding the toolset!

Alas, I'm not convinced it's quite that easy.  For example, this assumes we
bring in a new object at a fixed distance in front of the avatar, as we do now.
But I don't think we really should use a fixed distance. While I don't think we
should scale new objects to fit the scene, I do think we should use the size of
the object to figure out how far in front of us to put it, rather than a fixed
distance. For objects of different sizes, this reposition-the-avatar trick won't
work.  Hmmm. Can the external artist define a uniform "object size" for
everything that is supposed to be spatially registered against each other?

>
> b. Materials and textures should remain as-is. We should assume that designers
> have spent a lot of rendering time already trying to get to the desired result.
> If we have to start from scratch here, we gain nothing. Mostly what I am
> referring to here is the issue of texture mapping. From the few tests I ran,
> and I hope I am wrong, I think there isn't yet a connection between the source
> texture maps and what is created in croquet. Croquet needs to identify on the
> imported object: "This is a spherical mapping, so I must map it the same way,
> etc;"

This is outside my experience. Can you educate me? Do we have a bug?

[I know that it's just the start of a tool -- a hack really -- in what we
currently do with Copy Material and then Paste onto a mesh. Is that what you
mean? Or are you talking about the textures actually referenced within an .ase
file?]

Agreed!

At it's core, Croquet already allows anyone to define new behavior for objects
even as they are being used. This is based on Croquet being delivered on top of
a full Squeak Development Environment, and Squeak itself being what is called a
"dynamic language" (meaning that you can change definitions for already
instantiated objects). However, this requires a lot of expertise and doesn't
have any mechanism for live sharing of code changes among participants.

There are Croquet folks working on two different, but complimentary approaches
for next-generation scripting. They go way beyond what is normally thought about
for scripting, and are intended to leverage the extraordinary collaborative and
direct-manipulation capabilities of Croquet.

One approach provides a better and simpler model for defining how individual
objects "do" stuff, and how they tell things to other objects about what needs
to be done. (This is called Tweak.) In addition, more scripting languages (e.g.,
Python) are being supported so that programmers with a variety of backgrounds
can use this model.

 From the other direction, there is Brie, which allows very small bits of
encapsulated behavior (e.g., perhaps defined using Tweak and Python), and lets
these behaviors be directly manipulated (e.g., added and removed from objects)
just like any other object, using the normal user interface.
http://opencroquet.org/images/c/c4/2006_BrieUserExperience.pdf
http://www.wetmachine.com/itf/category/12

Ah, but the rewards for learning this stuff are so great! How else are you going
to make the world work the way you want it to?

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

> 2. How do you parse a file and generate a mesh (or instance of  
> another object)?  Croquet has long provided TLoad3DSMax for  
> handling .ase files.  There is also TLoadMDL for a file format used  
> by the Squeak Wonderland project (and no one else), but which  
> provides the avatars and other furnishings for a lot of the demos.  
> OBJImporter handles .obj files. The VRML package in the Contrib  
> repository (not pre-loaded in the CroquetCollaborative  
> distribution) provides the VRMLCroquetBuilder to handle .vrml/.wrl  
> files.

I would stay away from using OBJImporter unless you are using it to  
import an avatar that will be animated (say by a .bvh file). I've  
written a much simpler and more "correct" importer for .obj files.  
Here's a changeset with the new code:




Peter Moore
University Technology Development Center
University of Minnesota
[hidden email]

A software called "3D object converter", it merely converts all 3D file
formats existing today... It's a shareware with 30 days limitation. Hope
it helps.
http://web.axelero.hu/karpo/

Tim Wang

-----Original Message-----
From: haggai [mailto:[hidden email]]
Sent: Wednesday, March 14, 2007 7:03 AM
To: [hidden email]
Subject: [croquet-dev] importing models


Anyone knows of a 3DS to ASI (binary to ascii) converter? (besides
"Polytrans") that is very expensive)

h

It looks like you'll need to register this product for it to be any use with Croquet. All of the formats that we currently have importers for can't be saved with the trial version.

Have you considered Blender and its Python script add-ons?

Cheers,
Darius