PDA

View Full Version : LightWave 9.2: The Rebirth of An Industry Favorite



WilliamVaughan
04-21-2007, 11:31 AM
Steve Warner checks out LightWave 9.2 and says the powerful new features mark the rebirth of an industry favorite.

http://vfxworld.com/?sa=adv&code=57c5ed8a&atype=articles&id=3249&page=1

Tiger
04-21-2007, 11:55 AM
"Yes, these are definitely good times for LightWave users. The changes in 9.2 have brought improvements to nearly every aspect of the software and have made it overwhelming clear that LightWave 9 is the best LightWave to date."

I feel that Modeler also will have a major improvement in the 9.x cycles. :thumbsup:

SplineGod
04-21-2007, 01:06 PM
There seemed to be such an effort to get nodes to work with FPrime yet we still cant see them in opengl. Hope that changes soon.

hrgiger
04-21-2007, 01:47 PM
That was a very good review, and I mean that in both what he had to say about Lightwave and the way it was written. It almost made me want to go and buy a third seat of Lightwave.

He didn't mention any negatives as there are some to mention but he is right that Lightwave 9.2 is the best version of Lightwave to date, and this is only the first update to Lightwave 9. The features that we are getting in 9.2 are worthy of a .5 update. I can't wait to see what the actual .5 upgrade brings!

Bytehawk
04-21-2007, 03:22 PM
fluffy kittens !

adrian
04-22-2007, 01:21 AM
Great review, and this new version sounds awesome (the new radiosity & surfacing options really stood out for me).

I wonder when 9.2 will be available for us mere mortals to get our hands on it?

BazC
04-22-2007, 01:28 AM
as I mentioned in another post, we are looking to release early next week. Ran into a couple of bumps that needed smoothing. Of course, we could have released it anyway, I suppose... :)

http://www.newtek.com/forums/showthread.php?t=67314

:D

adrian
04-22-2007, 01:50 AM
Thanks for the link, that's raised my anticipation level still higher :)

JeffrySG
04-22-2007, 02:17 AM
Great article! thx for sharing the link!!

katsh
04-22-2007, 02:53 AM
people who dont have expriences and bought crazy expensive 3d app like xxxx will realize that what was they needed.
not only the ppl but also companys. company is ppl. ppl is company. its the natural result.

Lightwolf
04-22-2007, 03:42 AM
There seemed to be such an effort to get nodes to work with FPrime yet we still cant see them in opengl. Hope that changes soon.
That is one thing I doubt... like the GLSL option, it will require coders to completely duplicate the functionality (in code) for the preview.
As a side note, even texture layers don't have access to GLSL via the SDK. :(

I'm also not sure if GLSL is the way to go, especially since it does bring down performance quite a bit, even on the newest GFX hardware.

Cheers,
Mike

Dirk
04-22-2007, 03:52 AM
I like it! :D

mav3rick
04-22-2007, 05:31 AM
i think atm it is still not time to call it rebirth.... but my expectations about lw1 0 as completly rewriten mature app are big

mav3rick
04-22-2007, 05:32 AM
That is one thing I doubt... like the GLSL option, it will require coders to completely duplicate the functionality (in code) for the preview.
As a side note, even texture layers don't have access to GLSL via the SDK. :(

I'm also not sure if GLSL is the way to go, especially since it does bring down performance quite a bit, even on the newest GFX hardware.

Cheers,
Mike

i hope to see directx support by lw 10

Lightwolf
04-22-2007, 05:39 AM
i hope to see directx support by lw 10
You mean since we only have a mediorce openGL support now the dev team should spend time coding mediocre DX10 support as well?
Great ;)

I'd rather have openGL done right and then move on, and by the looks of it this will need at least LW 10.
Please note: Some steps are going in the right direction here (this is including LW 9.0), the speed up for geometry in Modeler and Layout are great. It also shows how much stuff there is left to do.

Oh, and I basically agree with the article (to get back OT) - the changes in the renderer/rendering pipeline make 9.2 a great update.

Cheers,
Mike

hrgiger
04-22-2007, 09:34 AM
That is one thing I doubt... like the GLSL option, it will require coders to completely duplicate the functionality (in code) for the preview.
As a side note, even texture layers don't have access to GLSL via the SDK. :(

I'm also not sure if GLSL is the way to go, especially since it does bring down performance quite a bit, even on the newest GFX hardware.

Cheers,
Mike

Yes, and now that there is Fprime support for Nodes, I see no need to have nodes display in OpenGL. As you point out, it would probably degrade performance to an unaceptable level.

achrystie
04-22-2007, 10:01 AM
Yes, and now that there is Fprime support for Nodes, I see no need to have nodes display in OpenGL. As you point out, it would probably degrade performance to an unaceptable level.

Except for those of us that aren't willing to spend, or capable of spending $400 on a preview renderer...

Although, I would agree that it is probably not necessary in the viewport.
I'd just like to see Newtek make Viper a little better/faster.

Cageman
04-22-2007, 10:13 AM
I hope that VIPER will get an update so that it can do things the FPrime-way...

Lightwolf
04-22-2007, 10:44 AM
As you point out, it would probably degrade performance to an unaceptable level.
That I wouldn't mind (hardware is getting faster).
However, looking at the current structure of the nodal editor I just don't see it happening from a coding perspective.
a) the system wasn't designed with openGL previews in mind
b) even if it could be made to work using GLSL, coders (including third parties) would need hooks to GLSL (which don't exist at the moment) and would then need to duplicate their code for the GLSL shading pipeline.

Cheers,
Mike

mouse_art
04-22-2007, 10:36 PM
Which 3d Software does preview nodes in GL/DX, on geometry?(apart from geometry deformation)

mouse_art
04-22-2007, 10:43 PM
Which 3d Software does preview nodes in GL/DX, on geometry?(apart from geometry deformation)

Damn Edit Lock.

Forget to write: (besides basic Surface Attributes)

I mean if you look from the work/economic standpoint (complexity ect.)

SplineGod
04-22-2007, 11:01 PM
I hope that VIPER will get an update so that it can do things the FPrime-way...

No kidding. At least beef this up to be somewhat more useable.

Red_Oddity
04-23-2007, 03:03 AM
That I wouldn't mind (hardware is getting faster).
However, looking at the current structure of the nodal editor I just don't see it happening from a coding perspective.
a) the system wasn't designed with openGL previews in mind
b) even if it could be made to work using GLSL, coders (including third parties) would need hooks to GLSL (which don't exist at the moment) and would then need to duplicate their code for the GLSL shading pipeline.

Cheers,
Mike

Any idea how Maya and XSI handle this then? Because they sure as heck have OpenGL previews of their node editors.

I wouldn't mind having some sort of 'basic' OpenGL previewing, FPrime does chugg down a lot when using more complex shaders with radiosity (say, simple skin or Kappa(I/II)), and turning off radiosity with every tweak inbetween sending scenes to the renderfarm is extremely prone to human error (forgetting to switch all those radiosity checkboxex back on)

Lightwolf
04-23-2007, 03:35 AM
Any idea how Maya and XSI handle this then? Because they sure as heck have OpenGL previews of their node editors.

By using pre-rendered image textures to a large extent.
However, their shading tree has also been designed for that.

The main issue is that they have a separation of texture coordinate generation and texture application (using the coordinates).
Texture coordinate generation is basically the generation of UVs using either UV maps or implicit projection modes (i.e. spherical, planar). Now, these UVs can be stored within the openGL mesh.
Texture application (the actual mapping process) only takes place in UV space then. And the app knows which texture coordinates are passed around and can use those to project low res proxy mages generated using the texture mapping nodes.
This is a simpler process for the application (and simpler for coders as well, since there is no need to cater for the projection modes in every single node you write... all you get are UVs to work on).

In LW there is no such separation, so the whole texture mapping process is opaque from LWs point of view. It can not extract as much useful information from the nodes (or texture layers). Especially not with the current SDK and taking third parties into account.

Cheers,
Mike

Red_Oddity
04-23-2007, 04:16 AM
This is gonna be a very useless post, but...

Aaah, offcourse.

Lightwolf
04-23-2007, 04:22 AM
This is gonna be a very useless post, but...

No it isn't. If it was a different post you'd have to endure yet another couple of paragraphs of me trying to explain things ;)

Cheers,
Mike