PDA

View Full Version : lightwave 2017 will not support old lwo format



vonpietro
02-01-2017, 07:13 PM
I've heard this from a few people.

I sincerly hope it is not the case.

What i need from lightwave 2017 is the ability to load my old objects without complaint, and not have it save a new format.
or have the option for it to save the old format.

If they have to save it as a new format - thats not so bad, but
i definately need the new lw able to load my old scenes.
if it doens't there is no point!!

hrgiger
02-01-2017, 07:52 PM
I remember hearing there will be a lwo3 format but I cant imagine it won't load lwo2 as well. Scene files will probably be a different story. But then, you can make an omelet without breaking a few eggs.

tburbage
02-01-2017, 08:28 PM
I remember hearing there will be a lwo3 format but I cant imagine it won't load lwo2 as well. Scene files will probably be a different story. But then, you can make an omelet without breaking a few eggs.

I don't remember reading that anywhere, but it seems likely. I can't imagine that they would not load lwo2, but it may well be a one-way street. We'll see (this year -- maybe? ;/ ).

Snosrap
02-01-2017, 08:56 PM
Yep it was stated in one of the threads by Lino or Rob that the new .lwo format eliminated the bottlenecks of some node connections. Don't remember the exact details but it something along the lines of going from a 16bit IFF chunk to 64bit. As far as compatibility, I think it stands to reason that the new format would not be compatible with older versions of LW. This change will really be more on the lines of the change in format from 5.6 to 6. In all versions of LW from 6 on up they have included an exporter to Lightwave 5. I doubt this will be that big of deal and it should really open up LW for future improvements. I for one want change even at cost of compatibility and can't imagine that old .lwo's won't be able to load into LW - surface attributes will get hosed but so what it's a new day. :)

thomascheng
02-01-2017, 10:18 PM
transfer it over with FBX, Alembic, or collada?

samurai_x
02-01-2017, 10:25 PM
Since they removed the besr bang for buck renderer in lw 2015 that could be the case.
So every buyer of lightwave next should get 2015 free.

vonpietro
02-01-2017, 11:11 PM
I really just want to be sure that i can load old modls in and old scenes.
granted some things would change, but if i can get most of it in - i'm happy.

m.d.
02-01-2017, 11:21 PM
Nothing stopping another reader from importing old .LWO

I think this is an unreasonable concern.....Houdini imports LWO natively....I really doubt the next version of LW would not.
They just needed to update the archaic old .LWO to a more modern coding standard




On a side note......although the next LW is still a permanent license....I have heard that's the new LWO format will be subscription only

wingzeta
02-01-2017, 11:58 PM
It would be odd if you couldn't load old models. .obj is a format .lwo is a format, it should be able to read it. Saving out after editing in the new engine, or loading in layout may be another story. Worse case scenario you would save a format like obj fbx etc, in an older LW version, and then import and fix surfacing. With the new render, surfaces will be broken anyway.

I say break the eggs to move forward. LW has a lot of catching up to do with the modern apps, and yet if it can break through those barriers, it could become very relevant again. The old architecture has prevented a lot of updating of tools, merging apps, and lots of other stuff. As far as I understand it, they lost 5 years on CORE, while the competition kept moving forward, then another few years playing patch up ...er catch up. If they can cause a little pain to get some of those lost years back fast, I'm on board. Because, for all of lightwave's faults, it is still a secret weapon for those who know how to use it, and if that secret weapon had access to some of the modern workflows and tools it doesn't currently, it would be a great advantage once again.

wingzeta
02-02-2017, 12:06 AM
Yeah, I heard that the new LWO format requires all your social media passwords, and an "always on" camera and microphone on your PC to work. You can skip all of that if you allow the new LWO to plant a chip at the base of your skull, and submit a sample of your brain tissue. The new LWO also takes the liberty of erasing all old versions of LW from your hard drive.:compbeati

samurai_x
02-02-2017, 12:44 AM
I really just want to be sure that i can load old modls in and old scenes.
granted some things would change, but if i can get most of it in - i'm happy.

The mesh data probably. But the material settings are totally different. Its a new renderer.
Just like if you use octane you will have to use its own material node system.
Hopefully newtek makes a loader converter thats idiot proof when opening old lwo files.

rustythe1
02-02-2017, 01:39 AM
Since they removed the besr bang for buck renderer in lw 2015 that could be the case.
So every buyer of lightwave next should get 2015 free.

but that would be pointless, if you had an old LW scene, you would already have the old lightwave you created it in,(they already stated that the issues with forward compat were these exact reasons) being as you can still continue to use your old lightwaves after upgrading,

samurai_x
02-02-2017, 02:34 AM
but that would be pointless, if you had an old LW scene, you would already have the old lightwave you created it in,(they already stated that the issues with forward compat were these exact reasons) being as you can still continue to use your old lightwaves after upgrading,

Not sure what you mean. If I was a lw 9 user and upgraded to lw next and all my lw files will not retain materials,etc then that's not good. I could atleast get up and running quickly if I get the last lightwave legacy version 2015.3 for free. And lw 2015 is still a vast improvement over 9.
It wouldn't be frustrating to use lw next in that case.

Anyway I'm sure newtek isn't stupid. They know they should make at least a legacy lwo loader for lw next even if the materials are not PBR.

kopperdrake
02-02-2017, 03:18 AM
I believe they were looking at producing a one-way translator for legacy assets, whether that was objects and/or scenes I forget.

mav3rick
02-02-2017, 04:45 AM
i dont see any logic not to run old .lwo... you probable think about converting surface settings as it appears only thing logic to me that would need tweaking if they use new .lwo format

MAUROCOR
02-02-2017, 05:36 AM
Yeah, I heard that the new LWO format requires all your social media passwords, and an "always on" camera and microphone on your PC to work. You can skip all of that if you allow the new LWO to plant a chip at the base of your skull, and submit a sample of your brain tissue. The new LWO also takes the liberty of erasing all old versions of LW from your hard drive.:compbeati


:lol:;D:ohmy::ohmy::ohmy:

lardbros
02-02-2017, 06:19 AM
I've heard this from a few people.

I sincerly hope it is not the case.

What i need from lightwave 2017 is the ability to load my old objects without complaint, and not have it save a new format.
or have the option for it to save the old format.

If they have to save it as a new format - thats not so bad, but
i definately need the new lw able to load my old scenes.
if it doens't there is no point!!

I wouldn't worry... Newtek wouldn't let this happen, I'm not sure who's passing this information over, but I'm certain it'll just be a load of B/S to try and do Newtek and LightWave down.

samurai_x
02-02-2017, 08:10 AM
I believe they were looking at producing a one-way translator for legacy assets, whether that was objects and/or scenes I forget.

I'm sure they're working on it. Thats what irked me with octane before.
Almost nothing was usable and you had to start from scratch.
Lightwave next has a totally new pbr renderer. It will be like using octane.

Verlon
02-02-2017, 08:21 AM
bear in mind that since Rob Powers came on board, Newtek has worked hard(er) at making Lightwave place nice in various pipelines. It would be rather odd to make LW2017 compatible with everything BUT older versions of Lightwave. As has been mentioned, FBX and Collada are always options.

sadkkf
02-02-2017, 11:02 AM
Building in backward compatibility is always a time-consuming task. Add this to the list of possibilities for the later release date.

Marander
02-02-2017, 11:31 AM
bear in mind that since Rob Powers came on board, Newtek has worked hard(er) at making Lightwave place nice in various pipelines. It would be rather odd to make LW2017 compatible with everything BUT older versions of Lightwave. As has been mentioned, FBX and Collada are always options.

The problem could also be that the new (LWO3?) format will be supported by ONLY LW 2017 but not for programs where it is currently supported as native format like 3DCoat, Vue, Terragen, C4D, Substance Painter etc. Some of them might update their support but only if LW has a significant market share. And for this to happen LW Next must really be a convincing release.

vonpietro
02-02-2017, 11:38 AM
The problem could also be that the new (LWO3?) format will be supported by ONLY LW 2017 but not for programs where it is currently supported as native format like 3DCoat, Vue, C4D, Substance Painter etc. Some of them might update their support but only if LW has a significant market share. And for this to happen LW Next must really be a convincing release.

THATS A GOOD POINT.

samurai_x
02-02-2017, 11:46 AM
That's not a problem. There's fbx and obj.
3dcoat, substance, and all these secondary appz can't open other files anyway like max, lxo, blend files, etc.

Marander
02-02-2017, 11:55 AM
That's not a problem. There's fbx and obj.
3dcoat, substance, and all these secondary appz can't open other files anyway like max, lxo, blend files, etc.

Yes of course but the conversion from and to fbx is always an extra step and then there are version differences. It's just more convenient. I can just open my existing LWOs directly in these programs without exporting them first. And so far there was really good LWO and even LWS support in many programs.

samurai_x
02-02-2017, 12:02 PM
I thought you moved on from lightwave? :D

Convenience or progress. I vote for progress.

Marander
02-02-2017, 12:26 PM
I thought you moved on from lightwave? :D

Convenience or progress. I vote for progress.

Haha yes I did, don't know when was the last time I started it :-) It is more or less useless on high res displays and I have no need for it at the moment. Still looking forward what LW Next has to offer.

TheLexx
02-02-2017, 01:29 PM
It is more or less useless on high res displays....Have I missed something there, could you please clarify ?

jwiede
02-02-2017, 02:06 PM
The problem could also be that the new (LWO3?) format will be supported by ONLY LW 2017 but not for programs where it is currently supported as native format like 3DCoat, Vue, Terragen, C4D, Substance Painter etc. Some of them might update their support but only if LW has a significant market share. And for this to happen LW Next must really be a convincing release.

Fair point, but I have difficulty believing LW3DG would _remove_ the ability to read/write LWO(1/2) files, just because they bumped the LWO version format for LW.Next (to LWO3, presuming that occurs).

Consider this: They've made past efforts to sustain LW's ability to load/save older LWS version formats despite bumping the LWS version format a couple times already. I seriously doubt they would suddenly behave differently w.r.t. LW's treatment of LWO files than they already do regarding LWS files.

Marander
02-02-2017, 03:03 PM
Have I missed something there, could you please clarify ?

Here some examples:

135862 135863 135864 135865 135866135865 135867

In some dialogs I would have to guess or know what the tabs and some other text fields are called, in others (like Hypervoxels) the dialog box / parameters is cut off (and cannot be extended in size). LW is the only program I have installed that has this problem.

Maybe somebody knows an easy solution (except changing Windows font scaling, because this fits perfect for all other apps). This machine is setup with 125% scaling but on the 4k screens it looks even worse with 200% font scaling. On FullHD display it works as expected.

Marander
02-02-2017, 03:21 PM
Fair point, but I have difficulty believing LW3DG would _remove_ the ability to read/write LWO(1/2) files, just because they bumped the LWO version format for LW.Next (to LWO3, presuming that occurs).

Consider this: They've made past efforts to sustain LW's ability to load/save older LWS version formats despite bumping the LWS version format a couple times already. I seriously doubt they would suddenly behave differently w.r.t. LW's treatment of LWO files than they already do regarding LWS files.

Yeah agree, if the legacy LWO / LWS save possibility is there, it's no problem. But I also read some beta leak that this should not be possible again in LW Next, old objects and scenes can be loaded but only saved in the new format as a one-way conversion (hopefully the rumour is wrong). But in a way it would be logic if they change geo and render engine. They mentioned that the old render engine is not present anymore and new cameras, lights, shaders etc. are required, so these would need to be converted with best effort into the legacy ones in order to save the legacy format. Same for geometry, materials, nodes and deformation stack if the internal object structure is very different it would need to be converted. Maybe this (backward compatibility) is what they have been working on for so long.

gamedesign1
02-02-2017, 04:23 PM
I really just want to be sure that i can load old modls in and old scenes.
granted some things would change, but if i can get most of it in - i'm happy.

I am sure that will be possible :) And then just save as the new format.

Spinland
02-02-2017, 04:41 PM
Too bad you can't keep old versions of LW around for legacy content—oh, wait...

Yes, this has already been mentioned. It's still the sole bit I have for the purposes of chiming in.

Nothing to see here, folks, move along. ;D

jwiede
02-02-2017, 05:18 PM
I do think the title of this thread also needs to be edited -- it's phrased as if a factual statement, when really it's just speculation.

jwiede
02-02-2017, 05:28 PM
Too bad you can't keep old versions of LW around for legacy content—oh, wait...

Well, in the case of LWO files, having old versions doesn't entirely solve the issue*: Because LWO2 has become such a commonly-used interchange format, were LW.Next unable to save in LWO2 at _all*_ it would impact ability to interchange objects with other LWO2-compatible apps like 3DCoat. Alternative formats could be used instead, of course, but doing so creates problems with retaining parts/layers/surfacing through round-trips. Having access to prior LW versions does nothing to improve those situations.

There's a related potential issue around libraries of pre-existing content, where "blind mixing" of LWO2 and LWO3 assets in libraries creates problems when attempting to access from apps only capable of loading/importing LWO2. There too, the access to prior LW versions doesn't really help such situations, the only real solution is to somehow block overwriting existing LWO2-format assets with LWO3-format versions, and having a separate LWO3-format library of updated/equivalent assets. This issue actually exists regardless of whether LW.Next can save LWO2-format objects.


*: I doubt the issue in question exists, this is just a hypothetical discussion.

MonroePoteet
02-02-2017, 05:53 PM
Since LWOB file format is chunk-based, and LWDG already has code to read and write all prior formats, it's really hard for me to believe they wouldn't support both forward and backward compatibility. One of the basic reasons for chunk-based protocols is that code can just ignore chunks that it doesn't know what to do with if the protocol is newer, and setting up good defaults for chunks that aren't present in older protocols.

Obviously, new functionality will not be backward portable. If they're going with PBR textures, for example, no old code would recognize that.

And, finally, LW's been very good about *publishing* the file format, so converters are bound to popup when / if needed. I'd guess LWDG makes it fully functional to legacy customers, since that's their bread & butter.

Just my 2 cents worth.

mTp

jwiede
02-02-2017, 06:50 PM
Since LWOB file format is chunk-based, and LWDG already has code to read and write all prior formats, it's really hard for me to believe they wouldn't support both forward and backward compatibility. One of the basic reasons for chunk-based protocols is that code can just ignore chunks that it doesn't know what to do with if the protocol is newer, and setting up good defaults for chunks that aren't present in older protocols.

Unfortunately, for LWO3 there's a good chance that will NOT be the case. Amiga IFF was intrinsically a 32-bit format, and so if they intend to change from 32-bit to 64-bit chunk lengths/offsets/etc. that's almost certainly a non-backwards-compatible change due to how IFF formatting is structured.

I can think of some convoluted tricks* to maintain files as both IFF- and "IFF64"-parsable (using parallel, distinct IFF & IFF64 structures within the file), but I'm not sure whether LW3DG will see such solutions as worth the additional file format (and therefore parsing code) complexity.

*: One method is similar to how PKZIP handled SEAs & 32-to-64 conversion, look that up for "long version". Briefly, old parsers read from the front and ignore the end, new parsers read from the end and extract the new data from a final directory chunk (that includes backwards-offsets to both IFF & IFF64 structures). I suspect that breaks some "formal IFF rules", but probably could work (I haven't actually confirmed, though, this is off top-of-head).

The "catch", of course, is that backwards-parsing trick only works once -- if the final directory chunk's capabilities won't support later changes needed, you're back to breaking compatibility, so you need to make that final directory chunk format extremely flexible/expandable. Such approaches have notable security implications as well.

Snosrap
02-02-2017, 06:59 PM
Maybe this (backward compatibility) is what they have been working on for so long. Gosh I hope not! Give me the new stuff - old stuff be dam#$%.

djwaterman
02-02-2017, 07:08 PM
Gosh I hope not! Give me the new stuff - old stuff be dam#$%.

I concur.

jwiede
02-02-2017, 07:18 PM
In some dialogs I would have to guess or know what the tabs and some other text fields are called, in others (like Hypervoxels) the dialog box / parameters is cut off (and cannot be extended in size). LW is the only program I have installed that has this problem.

It's an issue with the age of LW's GUI/UX engine, and unfortunately, requires _major_ changes to LW's GUI/UX engine to properly address. It's all because Windows apps' text and GUIs weren't DPI-scalable when LW's GUI code was written. That was added to Windows later, and so LW's GUI layout engine doesn't understand font-/DPI-relative scaling.

Oddly enough, this is an area where Mac LW is better off than Windows LW, because Mac apps' text and GUI's have always been DPI-relative, and so LW's GUI on Mac wound up with fewer DPI-specific dependencies.

jwiede
02-02-2017, 07:29 PM
Gosh I hope not! Give me the new stuff - old stuff be dam#$%.

I concur.

Studio/corporate LW customers consider asset compatibility a serious (read as: expensive) issue. LW3DG aren't likely to ignore those customers' concerns.

MonroePoteet
02-02-2017, 08:05 PM
Gosh I hope not! Give me the new stuff - old stuff be dam#$%.

So, you're recommending that I abandon hundreds, if not *thousands* of legacy objects? I'm happy that you have the time to re-make your legacy objects.

mTp

MonroePoteet
02-02-2017, 08:19 PM
Unfortunately, for LWO3 there's a good chance that will NOT be the case. Amiga IFF was intrinsically a 32-bit format, and so if they intend to change from 32-bit to 64-bit chunk lengths/offsets/etc. that's almost certainly a non-backwards-compatible change due to how IFF formatting is structured.

Hey, jwiede,

I dunno - since LWOB is text based, I'd expect incoming numbers (in whatever context) to be converted to 64-bit. Probably wrong. Ah, well.

mTp

P.S. ...too busy to make an accurate analysis...ah, well!

Snosrap
02-02-2017, 09:26 PM
So, you're recommending that I abandon hundreds, if not *thousands* of legacy objects? I'm happy that you have the time to re-make your legacy objects.

mTp

It won't go that far. The geometry will be fine - the surfacing will most likely not and that stands to reason with an all new render engine. The very basics of the surfacing may come over intact - think color and textures - but probably not much else. It will probably much like the usage of Octane is now - it requires the user to use its materials to make good use of its engine. The same is going to apply to Kray3 as well when it is finally done.

samurai_x
02-02-2017, 09:43 PM
It won't go that far. The geometry will be fine - the surfacing will most likely not and that stands to reason with an all new render engine. The very basics of the surfacing may come over intact - think color and textures - but probably not much else.

Exactly. That's acceptable going forward.
Third party renderers in other appz had the same problem with interpreting material attributes. It will never be 100% correct. And some manual tweakking always involved.
In octane renderer in modo the shadertree and octane nodal materials are not compatible. In lightwave the only stuff you can use are uvmaps and some tools to connect textures to the corresponding octane node. But everything else is done manually.

shrox
02-02-2017, 10:59 PM
Newtek! Answer definitively then lock the thread.

50one
02-03-2017, 12:06 AM
Newtek! Answer definitively then lock the thread.

They're too busy, coding 24hr/7.
Possibly around May there should be a quick and vague statement when one team member will be allowed to see the sunlight and have something to eat.

bazsa73
02-03-2017, 12:21 AM
Most surfacing setups are workarounds in order to imitate modern engines capabilites.
Who will miss those workarounds when we one go straight through the forest on a well paved path of modern shaders?

50one
02-03-2017, 02:05 AM
Most surfacing setups are workarounds in order to imitate modern engines capabilites.
Who will miss those workarounds when we one go straight through the forest on a well paved path of modern shaders?

Who knows what we are getting it's just promises atm and subject to change anyway.

pinkmouse
02-03-2017, 04:11 AM
My opinion.

1) LW needs a new file format.
2) It will load old files, but they will need tweaking to suit the new renderer/surfacing/cameras etc.
3) The new format will not be backwards compatible, but it will be possible to save old format objects with loss of data. Likely if you want to keep an old version of LW running you will need to duplicate your object library, one for new LW, one for legacy. Not an issue, hard drives are cheap.
4) Everything is speculation, including the above.

jwiede
02-03-2017, 04:35 AM
Hey, jwiede,

I dunno - since LWOB is text based, I'd expect incoming numbers (in whatever context) to be converted to 64-bit. Probably wrong. Ah, well.

LWS uses a text-based structure/representation (iow, format). LWO, based on IFF, is most certainly not a text-based format.

Take a look at how chunk and sub-chunk types and their lengths are represented, along with how many chunk and sub-chunk data formats are actually represented in LWO, and you can easily confirm they are binary-based not text-based. There may be chunks or sub-chunks whose contents are essentially text fields, but the skeletal structure of the LWO/IFF format itself, as well as many of the chunk and sub-chunk representations rely on packed binary data representations, not text.

MonroePoteet
02-03-2017, 08:57 AM
LWS uses a text-based structure/representation (iow, format). LWO, based on IFF, is most certainly not a text-based format.

Take a look at how chunk and sub-chunk types and their lengths are represented, along with how many chunk and sub-chunk data formats are actually represented in LWO, and you can easily confirm they are binary-based not text-based. There may be chunks or sub-chunks whose contents are essentially text fields, but the skeletal structure of the LWO/IFF format itself, as well as many of the chunk and sub-chunk representations rely on packed binary data representations, not text.

Yep, you're right. Sorry!

mTp

Dan Ritchie
02-03-2017, 11:23 AM
Yep... along the lines of going from a 16bit IFF chunk to 64bit. )

That would be good news indeed.

jwiede
02-03-2017, 02:08 PM
Yep, you're right. Sorry!

No harm, no foul. ;)

If LW3DG doesn't choose to do some elaborate backwards-compat. trick, I believe they need to change the file extension to something other than ".LWO". LWO is well understood to be an IFF-format file, etc. If they're breaking IFF compatibility as well as LWO compatibility, then IMO such a format isn't really an iteration of the existing LWO format anymore. It'll be a new, different format (and even format family), and so merits a new, different file extension.

Chris S. (Fez)
02-03-2017, 03:27 PM
It'll be a new, different format (and even format family), and so merits a new, different file extension.

Good thought.

tburbage
02-03-2017, 07:56 PM
No harm, no foul. ;)

If LW3DG doesn't choose to do some elaborate backwards-compat. trick, I believe they need to change the file extension to something other than ".LWO". LWO is well understood to be an IFF-format file, etc. If they're breaking IFF compatibility as well as LWO compatibility, then IMO such a format isn't really an iteration of the existing LWO format anymore. It'll be a new, different format (and even format family), and so merits a new, different file extension.
I had that thought as well -- .LW3, .LWO3, .LWM, .LW...something

samurai_x
02-03-2017, 11:11 PM
*.lwx :D

jwiede
02-04-2017, 05:11 PM
*.lwx :D

I almost suggested that in my post (esp. if LWO3 turns out to be a multi-object "container" format), but decided they'd be better off with something that more clearly indicates object/model somehow. From that perspective, ".LWM" is pretty decent (IMO, anyway).

shrox
02-04-2017, 06:23 PM
*.lwx :D

.42