Hi Michael,

> At any rate, I think that Styles in MoI will be the key thing to make this easier.

Yeah, we're waiting for it, so stop chatting and get back to work :)

Cheers

Hi Michael,

>>Yup, that's what the goal is - that Styles in MoI will become material assignments in an .obj file that you write out.

Will this work for .LWO format too?

Suggestion,To Include Collada file support, many programs and game engine's use it. LightWave CORE will also use Collada as it's main file format instead of LWO and LWS. http://www.newtek.com/core/techfaq.php
Modo 401 is having un official implementation of Collada import and export. (is also gonna be part of the SDK).

Awesome Danny!

I think it was movies like those from the 50's and 60's SciFi (as well as cartoons) That pushed me into design field in the first place.

Your model(s) and renderings are an inspiration! (Moment of Inspiration)

Michael T.

Hi Yannada,

> Suggestion,To Include Collada file support, many
> programs and game engine's use it.

I'd like to work on including it in the future at some point, but maybe it would help if I knew of a specific problem that it would solve for you.

I would just be writing the exact same data out that is already being written to .obj, .lwo, or .fbx format, all of which support shading normals and n-gons.

Is there a particular program that you are using that only works well with Collada format and does not handle any of these other formats?

I would think that the new LightWave would also be pretty focused on doing a strong support of .lwo since it will be necessary for supporting data created in previous versions of LightWave.

- Michael

Is all good here it was just a thought since there is a shift towards .fbx and .dae perhaps will be easier or less work for you if were to just support these. I think with .fbx .dae and .skp you are covered for every software out there, so you can forget .lwo .obj .3ds. Anyway I am not a specialist on data formats so I may be wrong, it just seems to me that Autodesk is pushing .fbx and collada is...

>> so you can forget .lwo .obj .

Please don't do that - I use these formats.

Plus I don't own, and am unlikely to own, any Autodesk products.

Same here ash ten years later I'm Autodesk free but I still have partner they do use Autodesk software .fbx exchange is good for that purpose. And Collada can cover the rest software out there, as I mention earlier Newtek is changing so collada it may be the easy way to go in the future, also for Modo users.

Hi Yannada, well adding a new format will involve more work, not less.

In general .obj seems to be the most widely supported format out there, so it is not practical to remove support for that.

For example if I removed both .obj and .3ds format, then I think export to ZBrush would not be possible, since it supports .obj and .3ds but not .fbx or .dae if I remember right.

Even with the new Lightwave having .dae as its default, it would be good to know if there was actually some advantage to using it instead of .lwo - like is their .lwo support buggy? (hard to imagine since they need to support a ton of old .lwo files) Or is there some kind of special function that is only available in .dae and not in .lwo ? (Something that applies to MoI I mean, for example animation type data doesn't really apply to MoI's exports since MoI is focused only on modeling and not on animation tools).

It is hard to make it a priority unless there is an actual practical advantage to be had for it.

- Michael

Hi Tony,

> Will this work for .LWO format too?

Yup, that is the idea as well...

The way that LWO is structured does not quite exactly line up as easily as .obj though.

In LWO polygons can be marked to have a "surface" assignment - a surface is a render material. So I was thinking that probably styles would map to that.

Then there is also something called a "layer" which is a grouping of polygons. It's kind of like a cross between an "object" and a "group" sort of... I think that possibly groups or named objects could be translated as different LWO layers.

It's a little tricky because there isn't quite the concept of a single "object" in the file structure, the closest thing to that is a layer I think. This is a little different than what a "layer" is in a CAD program.

- Michael

Damn those renders are HOTT - EXCELLENT WORK!

-Will

>> Yup, that is the idea as well...

Great.

Mapping groups and stuff sounds cool too. I wonder how modo will handle it (I don't actually have Lightwave so only interested in this as a means of getting data from MoI to modo).

modo has a concept of polygon tags. Select a bunch of poly and assign a tag to them. This can then be used to map materials to specific polys. This looks like how the 'surface' assignment is translated. Makes sense to have style mapped to this.

modo then has mesh items which look like they matche with the 'layer' concept. At the moment each object in MoI comes over as a new mesh item called obj1, obj2, etc. A mesh item is just a group of polys, connected or unconnected. Polys can be cut and pasted between mesh items and the mesh items can be turned on/off, grouped or instanced. They are displayed like layers in the item list, along with other objects.


So I think you are right that the layer is the closest thing to a single object. Proof is in the eating of course :-)

Hi Tony,

> modo then has mesh items which look like they matche with
> the 'layer' concept. At the moment each object in MoI comes
> over as a new mesh item called obj1, obj2, etc.

Yeah, currently when MoI writes out a LWO it puts each object in MoI on a different LWO "layer" with automatically generated names obj1, obj2, etc...

So those are what end up as a 'mesh item' in Modo.

It seems like I've heard from some people though that this can be inconvenient to have things split up into too many different mesh items in Modo with more complex models though.

Yeah the "tags" terminology is also used in LWO format, for values that can be assigned to faces. There is a "SURF" tag that assigns a surface to a polygon, and I just reviewed the LWO docs and saw that there is a "PART" tag that can be used to make a polygon belong to a named group.

But neither "PART" tags nor layers in LWO are hierarchical (with a parent/child type structure) so I'm not sure if groups in MoI will map to either one of those very well.

Yes, styles going across as surfaces seems to make the most sense for that part.

And what I'm thinking now is that I should make named objects in MoI translate across as layers, and if you assign several objects in MoI the same name then I can combine those objects together to make just one LWO layer out of them. Otherwise unnamed objects can go across same as now as "obj1", "obj2", etc...

- Michael

Hi Michael,


>> It seems like I've heard from some people though that this can be inconvenient to have things
>> split up into too many different mesh items in Modo with more complex models though.

The main thing I have found inconvenient is that they all have the name obj[X] so I don't really know which thing is which without selecting it. My first step is to group similar items together. Knowing what the thing is called makes it easier to group similar items.


>> And what I'm thinking now is that I should make named objects in MoI translate across as layers,
>> and if you assign several objects in MoI the same name then I can combine those objects together
>> to make just one LWO layer out of them. Otherwise unnamed objects can go across same as now as "obj1", "obj2", etc...

My first thought was that this would be very useful. If I had 20 objects in MoI all called switch then they would all be in the same mesh item in modo. If I had one object called outer casing and one called inner casing then they would end up as separate mesh items. Cool.

My second thought was how could this all be managed in MoI with lots of things with the same name - then I remembered groups and thought, no problem.

My third thought was that I have missed a trick when working in modo. All my Brain Amplifier objects are single mesh items (because they imported that way). Similar ones are grouped together. But I could also have had similar objects merged into one mesh item, for example all switches for a single panel. I would have had a much simpler structure in modo :-)

I think your idea would make this organization work much better across both apps. Doesn't look like MoI groups will translate over to modo groups through the lightwave format though - shame :-(


Of course I have to ask, any chance of being able to export to modo format (.lxo) at some point? Do Luxology publish info on their formats?

Hi Tony, well it sounds like that will be a good step forward.

That part probably will not be ready by this very next beta but probably the one after, for this next beta I'm focused on just setting up the UI within MoI.


> Do Luxology publish info on their formats?

No, not as far as I can tell.

The only SDK that they have seems to be a plugin system for writing File I/O plugins for Modo, and not a file format specification for how to read or write that format from a different application.

Do you know of what differences there are between .lxo and .lwo? It seems that Modo is structured very similar to the .lwo format already, so I'm not quite sure what the differences are.

- Michael

>> That part probably will not be ready by this very next beta but probably the one after,
>> for this next beta I'm focused on just setting up the UI within MoI.

No problem. One step at a time ;-)


>> The only SDK that they have seems to be a plugin system for writing File I/O plugins for Modo,
>> and not a file format specification for how to read or write that format from a different application.

Ah ha, this explains some of the complaints over at the Luxology forum about a lack of SDK for modo.


>> Do you know of what differences there are between .lxo and .lwo? It seems that Modo
>> is structured very similar to the .lwo format already, so I'm not quite sure what the differences are

No sorry, never had Lightwave so don't know how this works.

>> Do you know of what differences there are between .lxo and .lwo? It seems that Modo is structured very similar to the .lwo format already, so I'm not quite sure what the differences are.

Hi Michael,

.Lxo is a complete scene format, storing objects, light setups, camera, animations etc ... while .lwo is 'just' an object format.
In fact .lwo is not used anymore in modo, it's just there for data exchange with lightwave


In lightwave stuffs were splitted into 2 formats, .lws (that can be edited in a simple txt editor) for the scene, and .lwo for the geometry.

Hi PaQ - thanks, that clarifies it some more.

But what about only considering the mesh object data inside of a .lxo file - it seems likely that particular part of the data is pretty much the same as .lwo format object data...

Is there some kind of mesh data that does not survive an export from Modo to .lwo format and back in again for example?

- Michael

>> Is there some kind of mesh data that does not survive an export from Modo to .lwo format and back in again for example?

Nothing as far as I know ... only shading descritpion is lost. (In fact basic texture maps in common slot like diffuse, specular, bump are preserved ... but advanced
settings that is to much different from lw don't work of course)

You can even rename a .lwo into .lxo ... it will load perfectly in modo (I'm not sure it will prove anything :))

*Edit

They are some little stuffs that are still not preserved

- Patch geometry
- UV's are allways stored back to linear

Btw I've renamed a .lxo into .lwo, but the file can't be loaded in lightwave modeler.

I almost forget :

Nice rendering Danny ! Maybe the glass material can be a little bit enhanced ? (adding some refraction ? fresnel on the reflection ? I don't know ... looks just 'transparant' for the moment)