[Tyrone Marshall]

There is no need for all those free formats.


Basically i think the most important formats are: (comments from polytrans)

1) 3ds . It is old, it is bad, its from dos days, but everyone uses it

".3ds is no longer an ideal file format as it once was. The .3ds format has several serious shortcomings, many of which probably stem from the fact that 3D Studio R1 grew out of Tom Hudson's mid-80's "CAD-3D" on the Atari platform:

* All meshes must be triangles.
* All texture filenames are limited to 8.3 DOS character lengths.
* The number of vertices and polygons per mesh is limited to 65536.
* Accurate vertex normals cannot be stored in the .3ds file. Instead "smoothing groups" are used so that the receiving program can recreate a (hopefully good) representation of the vertex normals. This is still a hold-over legacy for many animation programs today which started in the 1980's (3DS MAX, Lightwave and trueSpace still use smoothing groups, and Maya up to v2.51).
* Object, light and camera names are limited to 10 characters. Material names are limited to 16 characters.
* Directional light sources are not supported."

2) Wavefront obj

"The Wavefront OBJ file format itself does not include any capabilities for vertex color information, lights, cameras, NURBS, animation or skeleton/skinning information. Even so, it's a very standard and good format for general 3d mesh model conversion and archiving."

3) vrml2

Will output all infomartion: Material, Hierarchy,u/v,mesh vertex colors, Lights&Cameras,NURBS,Anim.

Last but not least the u3d file format (which is just new) and for which you can see info http://www.intel.com/technology/systems/U3D/

I did not know vrml2 was so robust. I agree ".3ds" is no good. "*.obj" is showing its age as well.

I vote for vrml2!

[cyberjuls]

*.FBX is so far the best format i founded to get CAD stuff in XSI.

Oh and yes can someone from nextlimit could tell me if it is possible to simulate a camera that have an "objectif a décentrement". Basically, in real world you use this to have correct verticals when shooting from under a building. It avoid more or less the perspective effect but just on the up axis.

This one would be really cool

more info there ::> http://www.arnaudfrichphoto.com/techniq ... -photo.htm

[DELETED]

DELETED

[ludi]

this GUI is from SolidWorks (no joke, they want to proselytize our next generation=> the children of today)


http://www.cosmicblobs.com/about_us.html

[Frances]

I don't know as much as I'd like to about the proposed GUI and material editor, especially, whether or not it will evolve much past what it is now (a basic viewer with some exposure controls).

If Next Limit intends to develop the GUI into a full standalone product like Lightscape, then (to me) it would make sense to either have robust file import supporting many common file formats or provide simple export plugins for the modeling programs that are proposed.

As a Rhino user, this does not fulfill my dream of having a high-end renderer built right into Rhino with no obvious export issues. But from a developer's point of view, it alleviates a bazillion headaches regarding having to write custom plug-ins for 10 or so applications (that have to be redone if a new version of the host app is released that in incompatible with current plug-ins). A full program such as Lightscape might be out of the scope of what Next Limit had in mind though. The tough work would all be upfront, with the simple part - geometry export plug-ins for proposed apps following. I guess the import/export coding is already done regarding mxl's ability to talk to host applications.

I love the Rhino plug-in, and it will be aces once some sort of UV mapping capabilities is implemented (either by McNeel in V4, by NL, or by a third party).

Baby crying. Gotta go.

[Kabe]

All this ideas about exchange formats neglect a quite important fact:

If you *need* another app in the pipeline just to apply textures things get clumsy, if you like it or not. Using a Maxwell GUI to texture means to learn a new app, to use another app, and it'll take much more time than doing it in the application you use for modeling. If it's just an option: fine. If this is required, it's gone.

So the bottom line is:
*Applying* textures should generally take place in the host app.

So how can NL get there? I guess they already started with the right intention: Provide a rock solid Maxwell SDK with good documentation that allows writing a cool exporter/render plugins. You don't believe me? Look at Matador Light, that clearly shows the merits of such a approach.

Now to the part that I think will decide if this works out or not:

NL mustn't try to support all the intended host applicatons on their own, this is *not* their core competence - and it shows. It costs an awful lot of energy that better should be put into the SDK and the core app.

They need to find a business model how to support competent plugin writers that know their host platform really well. For many applications they could easily get results which are much more valuable than what NL could do in their own.

*Designing* the Maxwell materials is another story. This could and probably should take place in a standalone app coded by NL, which would also support the idea of platform and host independent materials, and so would also allow material exchange across boundaries.

So much from me

Kabe

[Mihai]

So the bottom line is:
*Applying* textures should generally take place in the host app.

I agree, and when you have straight UV information, it shouldn't be a big issue transfering them to Maxwell's GUI. Question is about tiling...I guess that should be an option left to Maxwell than the host app.

Also the most important work flow feature to me would be to maintain a live link of scenes between host app - Maxwell. Imagine if you have a scene with hundreds of objects and you add a few verts to one object. What happens then to the scene you already exported to Maxwell? It must keep track of objects to see which ones need updating because redoing the whole scene after each change will seriously cripple Maxwell usage...

[Polyxo]

As this thread became active again:

THis are strick CAD files. I dont think you can use them AS IS with any renderer. Even if you convert them to 3ds or obj (using polytrans for example) i think they still need some work with a 3d modeler.

Just for the record: Rhino will render the following step file-types with Maxwell:
AP214AutomotiveDesign
AP214AutomotiveDesignCC2
AP203ConfigControlDesign

Very likely that SW also offers some of these options.
Maybe useful for Miles

Holger

[Miles]

As this thread became active again:
Just for the record: Rhino will render the following step file-types with Maxwell:
AP214AutomotiveDesign
AP214AutomotiveDesignCC2
AP203ConfigControlDesign

Very likely that SW also offers some of these options.
Maybe useful for Miles

Holger

Thanks a lot for the confirmation, Holger.

Rhino seems to be the path of least resistance...

Alibre - plug-in to - Rhino - plug-in to - Maxwell

Miles

[Kabe]

So the bottom line is:
*Applying* textures should generally take place in the host app.

I agree, and when you have straight UV information, it shouldn't be a big issue transfering them to Maxwell's GUI. Question is about tiling...I guess that should be an option left to Maxwell than the host app.

Please, support tiling in the host is a must, at least for the basic things like uniform repetition and offset. The non-functioning tiling support in the earlier Cinema plugins was a killer so nobody used textures at all.

When it comes to different tilings for the different channels, this might be a bit different, but basic tiling is really of such importance that not supporting it in the host means not to support it at all in the perception of the users.

Also the most important work flow feature to me would be to maintain a live link of scenes between host app - Maxwell. Imagine if you have a scene with hundreds of objects and you add a few verts to one object. What happens then to the scene you already exported to Maxwell? It must keep track of objects to see which ones need updating because redoing the whole scene after each change will seriously cripple Maxwell usage...

This is one thing that becomes incredible complicated, because Maxwell can't easily keep track of the host application. It would also need different solutions for each host application to do so.

In fact the point you made is another very strong support for the idea to put as much functionality as possible into the plugins, because they use the internal scene structures. Reducing it to an export and doing the texturing and tweaking in Maxwell *will* kill the workflow completely, you can rely on that.

Kabe

[Miles]

Excuse me if this is naive (still a beginner at rendering).

Why can't a format like X3D be adopted for interchange between modellers and rendering programs? The present state of affairs (for CAD as well) seems pretty squalid and inefficient.

[juan]

Hi Kabe,

You are almost absolutely true

[KRZ]

maxwell should be integrated into as many 3dapps as possible and as tightly as possible...see brazil, mental ray, aso.

another approach would be pretty non-sense

[bakbek]

Well... the first premise for maxwellrender was a standalone app with a GUI. Now I don't know what did that originally meant for the NL team… I know what I thought about it – a renderer application that I 3D platform independent, that is I can model were ever I want and then import this model into Maxwell for texturing and lighting, with some sort of live connection based on geometry or basic materials assignments in the host app.

If a true integration is to be implemented for all 3d platforms the I'm afraid that we will have something like VRay or FR – a renderer for he most popular app first with others suffering from less functionality and only later on all the rest will catch-up.

I Hope I'm wrong.

[DELETED]

DELETED