PDA

View Full Version : What are the advantages of unifying Layout and Modeler



Julez4001
07-28-2012, 08:24 PM
What are the advantages of unifying Layout and Modeler?

I hear that if Newtek do not unify the two applications then its will remain in the stone ages?

I just do not follow.
Every major app that does have a unified workflow has to come up with some type of referencing technique, plugin or import.


What are the major bonuses that you get with having everything in one app.

Dexter2999
07-28-2012, 08:31 PM
What other "major app" does not have a unified workflow?

Philbert
07-28-2012, 08:37 PM
What other "major app" does not have a unified workflow?

So your reply is that everyone else does it so we should follow the herd?

JonW
07-28-2012, 08:52 PM
I like Modeler & Layout as they are.

I like names on buttons to jog one's memory when I forget a shortcut (getting old!). I would take a rope it they changed the interface to an amateur eye candy layout. At least there is one company left that has sensible & efficient interface, but a few tweaks would help.

Would like to see more cores used!

Dexter2999
07-28-2012, 09:02 PM
"Follow the herd"? Not necessarily.

I personally like the division of toolsets and think LW feels less cluttered in some respects than other programs.

But advantages, would include not having to rely on the HUB and/or manually update & save models then Sync them with Layout. (Also gets rid of questions like "Why isn't this object layer updating in Layout?" )

Being able to model while looking through the camera.

Create and edit weight maps without switching back and forth.

Assign textures without switching back and forth.

Off the top of my head.

I have always maintained that should LW become unified I would love to see the F12 become an option to merely change the tabs and tools, to keep the feel of the current workflow...but without the limitations.

Philbert
07-28-2012, 09:10 PM
Across like 4 of my own computers and of course others at jobs and school I've never had a problem with the hub. It's pretty much always worked exactly as it was supposed to.

geo_n
07-28-2012, 09:10 PM
So your reply is that everyone else does it so we should follow the herd?

This particular herd is strong so why not follow it and not get left behind. :D
Would you want 3dcoat to split into completely separate appz for painting, sculpting with a hub connecting them? :D:D



And whoever wrote this in lw 11.5 page needs to remove it. Other software hassles?? :ohmy:
The hassle is saving multiple lwo version and updating them indvidually all the time something changes.

----------------------------------

ASCII Text-Based Scene Files and Object Referencing

The LightWave architecture is well thought out. LightWave has had a very efficient and robust ASCII based scene file format from the very beginning. This production-proven text-based scene file format set the standard which other professional software packages have eventually followed. Because of this simple, well thought out ASCII scene file format and the way that LightWave references separate object files you never run the risk of a large all inclusive binary scene file corrupting your assets. Additionally, LightWave's text-based scene file format allows for amazing flexibility and customization within complex pipelines when coupled with the powerful Python scripting language.

The way that LightWave references separate object files is also extremely powerful and flexible in a pipeline. This means that the modeling team can be updating the object files as the design progresses and those objects are instantly updated across all scenes in the production. Or you can try different looks on your character rigs with a simple object replace with none of hassles that you might encounter in other software packages.

Philbert
07-28-2012, 09:14 PM
Would you want 3dcoat to split into completely separate appz for painting, sculpting with a hub connecting them? :D:D


Of course not but 3D-Coat is a much smaller and more specialized app. If it had animation and camera and particles and dynamics, etc, then yeah I very well might like it to be split. I didn't say whether I like LightWave being split or not, it certainly has advantages though.

geo_n
07-28-2012, 09:21 PM
Of course not but 3D-Coat is a much smaller and more specialized app. If it had animation and camera and particles and dynamics, etc, then yeah I very well might like it to be split. I didn't say whether I like LightWave being split or not, it certainly has advantages though.

Yet the other herd has animation and camera and particles and dynamics ,etc, but they are doing great in a unified environment.
Come on Phil, I know you love lw and 3dcoat very much. But you can't be too much into it to reject the advantages. I started the zbrush 4.4 thread at 3dcoat forums and you completely dismiss its features. I would love to have those features in 3dcoat in the same way I would love to have features from other software in lw. That goes both ways. I would love to have some lw stuff in max.

xchrisx
07-28-2012, 09:38 PM
Some of the advantages of having them combined are:
* Ability to model to the camera for matching geometry to film plates
* Possibility to model on top of dynamics simulations to fix errors
* We could possibly use LS Commander for modeling commands to record macros
* We could eliminate things like the hub which work sporadically
* There wouldn't be issues with loading models that contain layers, if the model's layer numbers get changed
* When rigging, corrective morphs could be made quicker and more accurate, weight maps could be fixed more easily as well
* Models could be edited when using displacements if there were problems due to geometry

I am sure there are plenty more examples of why it would be very beneficial if the 2 apps were merged, but these were the ones off the top of my head.

Philbert
07-28-2012, 10:09 PM
Yet the other herd has animation and camera and particles and dynamics ,etc, but they are doing great in a unified environment.
Come on Phil, I know you love lw and 3dcoat very much. But you can't be too much into it to reject the advantages. I started the zbrush 4.4 thread at 3dcoat forums and you completely dismiss its features. I would love to have those features in 3dcoat in the same way I would love to have features from other software in lw. That goes both ways. I would love to have some lw stuff in max.

Are you only reading the parts of my post that you want to read? I specifically said I was not for or against it in LW. I did not reject anything. I simply said there are advantages to it being split. There are also advantages to it being merged. Hence me not being for or against. Same goes for 3D-Coat I'm sure if it ever happened. If done well a merge can be pretty OK. Not many apps do it well though.

hrgiger
07-29-2012, 02:41 AM
People think that if modeler and Layout are seperate, that you will use less system resources which isn't true.

Some also think that a unified application's interface will be too cluttered. This is solved with workspaces only putting the relevant tools for a particular task on the screen at one time (ie, modeling, animation, UV mapping, simulation, etc...) Not all that dissimilar to the way for example current modeling is broken down into spaces like create, modify, construct....

I've really not seen any good reason to keep modeler and Layout seperate.

Some of the numerous advantages:


Weighting in the animation environment
Animation of modeling operations
Camera view while modeling
Creating corrective morph targets in the animation environment
Using VPR as you model
Making changes to your scene at the component mode (point, edge, polygon,item...) in layout setting
Using modeling tools to edit animation rigs
Modeling tools in the node editor
Modeling tools as animation deformers

Greenlaw
07-29-2012, 02:51 AM
For me, unification would mean being able to edit a character's mesh, endomorphs, and weight maps while it's in a posed position. This is essential for creating proper joint morphs and other corrective adjusments. Right now there's a lot of trial and error involved when jumping back and forth between Layout and Modeler--not a very productive situation. I'm hoping Genoma addresses this but we'll have wait and see what it actually does.

Same is true when setting up a scene for advanced camera projection. The third-party Mesh Edit plug-in helps but editing objects with this tool in Layout is still very limited. Plus, it only works in x32 and I hardly ever run Layout in x32 anymore.

G.

Philbert
07-29-2012, 02:57 AM
People think that if modeler and Layout are seperate, that you will use less system resources which isn't true.

How is this not true? a smaller program in memory is a smaller program in memory correct?


Some also think that a unified application's interface will be too cluttered. This is solved with workspaces only putting the relevant tools for a particular task on the screen at one time (ie, modeling, animation, UV mapping, simulation, etc...) Not all that dissimilar to the way for example current modeling is broken down into spaces like create, modify, construct....

Speculation. It could be handled with workspaces, if they do it that way and do it well. But you don't know that this would happen. Not all unified programs handle this workspaces thing very well. Don't get me wrong, like I said it could be done well.

There are some benefits to merging if it's done well.

50one
07-29-2012, 02:59 AM
Two separate apps, modeler with no camera view? Set extensions anyone?

I've gor a small suggestion...why reinvent the wheel and mix the tools from both apps? Why not have two apps unified, but have tabs with "modeler" and "layout" ? Something ala Modo?

Hah Philbert beat me to it, he mentioned workspaces as well..:)

Philbert
07-29-2012, 03:02 AM
I've gor a small suggestion...why reinvent the wheel and mix the tools from both apps? Why not have two apps unified, but have tabs with "modeler" and "layout" ? Something ala Modo?

Hah Philbert beat me to it, he mentioned workspaces as well..:)


I was only responding to hrgiger who mentioned it before me. These work spaces are typically how most of the "unified" 3D apps work. blender does it too. This is also the way CORE was going to work.

juice
07-29-2012, 03:05 AM
I think there are some jobs, where the separation is ok, but there are also jobs, where a separation makes no sense!!
An example of my daily work, I get a shot for set extension, before I pass it to the matchmove-department, I test if I can finish the shot without having to wait, I try a 3d track in Nuke, I save the pointcloud as fbx, than I can open it in an 3d application... personally I think because of the point by point modeling features and better splines workflow, I love to use Modeler... but there I dont can see if my model match in the scene as I am modeling!! So I have to stick with Maya, where I can see how my model is working during the different frames...

Kuzey
07-29-2012, 03:52 AM
Why not have all the tools in one giant database structure and to access them..you just open a new window (like a web browser), customize to suit unified or two app solutions and off you go?

My only concern with a unified app...how do I model while I render something else at the same time...on the Mac :D

Kuzey

geo_n
07-29-2012, 05:35 AM
Are you only reading the parts of my post that you want to read? I specifically said I was not for or against it in LW. I did not reject anything. I simply said there are advantages to it being split. There are also advantages to it being merged. Hence me not being for or against. Same goes for 3D-Coat I'm sure if it ever happened. If done well a merge can be pretty OK. Not many apps do it well though.

Read your post. Just because the herd is doing , etc. Its not for isnt it? Its even sarcastic.
Just like zbrush features, sarcastic response. Making it sound like 3dcoat has little to gain from copying features. Zbrush copied features in 3dcoat. Good fo zbrush. Why cant we do the same?

wesleycorgi
07-29-2012, 06:26 AM
And whoever wrote this in lw 11.5 page needs to remove it. Other software hassles?? :ohmy:
The hassle is saving multiple lwo version and updating them indvidually all the time something changes.

----------------------------------

ASCII Text-Based Scene Files and Object Referencing

The LightWave architecture is well thought out. LightWave has had a very efficient and robust ASCII based scene file format from the very beginning. This production-proven text-based scene file format set the standard which other professional software packages have eventually followed. Because of this simple, well thought out ASCII scene file format and the way that LightWave references separate object files you never run the risk of a large all inclusive binary scene file corrupting your assets. Additionally, LightWave's text-based scene file format allows for amazing flexibility and customization within complex pipelines when coupled with the powerful Python scripting language.

The way that LightWave references separate object files is also extremely powerful and flexible in a pipeline. [/B]
I would like NT to make LWOs ASCII, because textures are embedded in LWOs. I'm finding it easier to modify OBJ/MTL and ASCII FBX via text editors. And as a result, I can create AppleScripts for repetitious tasks.

Or perhaps one of the compelling unification arguments is surfacing. It kills me that if you have multiple separate LWOs in a scene, you can't make global material changes. You have to copy and paste between the respective surfaces then save all objects. If you need to tweak the same surface, then you have to repeat all the copying/pasting.

<unsolicited plug>That's why I'm digging TrueArt's Global Materials plug-in right now.</unsolicited plug> Nowadays, most of my surfacing is performed in Layout vs. Modeler via Global Materials (and interestingly enough it forced me to go nodal as well).

HenrikSkoglund
07-29-2012, 06:46 AM
I really hope that if/when Newtek unifies the Modeler with the Layout, that they keep the way the layers are handled. I think this is really good as it is and much easier to handle than for example Modo's shader tree-way of handling the mesh parts.

Also, let's just hope it's not going to get Lightwave cluttered... these things is some of the reasons I like Lightwave now.

Sensei
07-29-2012, 07:23 AM
<unsolicited plug>That's why I'm digging TrueArt's Global Materials plug-in right now.</unsolicited plug> Nowadays, most of my surfacing is performed in Layout vs. Modeler via Global Materials

Me too. Even not because I need global copying'n'pasting. But it's so much easier to not have to select surface, pressing Edit Nodes, then do something, then selecting other surface, pressing Edit Nodes etc. etc. etc. after many such senseless clicking I am annoyed..


(and interestingly enough it forced me to go nodal as well).

I am like Chuck Norris - forcing people to do things the way I want.. :p

cresshead
07-29-2012, 08:13 AM
Q.What are the advantages of unifying Layout and Modeler?

A better question could be
WHY was LIGHTWAVE 3D conceived as 2 separate applications in the first place?

answer - memory limits on the amiga i believe is the reason for the 2 applications being created.

jwiede
07-29-2012, 08:25 AM
I didn't say whether I like LightWave being split or not, it certainly has advantages though.
The advantages of unification have actually been enumerated many, many times in these forums. Still, I can briefly enumerate (again) some of the major ones. Perhaps then you can enumerate some of the advantages a "separated" app offers that a unified app in incapable of offering efficiently?

Efficient Animation Access to Modeling Tools
Efficient Modeling Access to Deformers
Parametric Models/Objects Available End-to-End
Decreased User Education and UX Familiarization
Decreased Engineering Costs Maintaining One App
More Efficient Third-Party Plugin Development and User Scripting

I'm sure I've probably forgotten some major ones, those are just the big ones that lept to mind.

NOTE: While 1 & 2 can be (partially) addressed by duplicating tools between apps, doing so inherently worsens 4, 5, and 6. Duplication of tools just isn't a sustainable long-term solution -- even if adding deformers to Modeler and modeling tools to Layout were efficient to implement, the increased volume and complexity of code that would result significantly increases / worsens the burden imposed on future engineering development overall.

Unfortunately, the toolset duplication approach fails to address that many to most users of each toolset are additionally dependent on external app-specific plugins' additions to the toolset as well. Unless duplication can grant users access to those external plugin tool dependencies, the duplicate toolsets remain significantly less capable / "complete" than their original counterparts. Yet granting that access would invoke even further development inefficiency over the long-term. The toolset duplication approach is a lose-lose situation.

wesleycorgi
07-29-2012, 08:36 AM
But it's so much easier to not have to select surface, pressing Edit Nodes, then do something, then selecting other surface, pressing Edit Nodes etc. etc. etc. after many such senseless clicking I am annoyed..


Interesting, I haven't realized this until you mentioned it --- but I am clicking a helluva lot less with Global Materials!

Paul_Boland
07-29-2012, 08:50 AM
What grinds my teeth with Lightwave having Modeller and Layout as two seperate programs is that I model in Modeller, setting up texture areas. Then have to go into Layout to put on the textures. If I then want to make a change to a text area, change it to another texture, it's back into Modeller to make the change, then back into Layout to apply the texture. AGH!! Having a unifed Lightwave means there's no jumping around between two programs.

Sensei
07-29-2012, 08:54 AM
? Layout and Modeler have duplicated tools? Where?

Move in Layout is operating on envelope channels.
Move in Modeler is operating on vertexes.
Two different worlds.

If there will be one app, you will have still two Move commands anyway..

wesleycorgi
07-29-2012, 09:17 AM
What grinds my teeth with Lightwave having Modeller and Layout as two seperate programs is that I model in Modeller, setting up texture areas. Then have to go into Layout to put on the textures. If I then want to make a change to a text area, change it to another texture, it's back into Modeller to make the change, then back into Layout to apply the texture. AGH!! Having a unifed Lightwave means there's no jumping around between two programs.

Hi Paul,

Unless I'm not following you correctly, I think you may be able to save a step or two in your current process. You can make the texture changes in Layout and then do a "Save Object" to update that object --- no need to necessarily go back to Modeler. Also, I used to do all my texturing in Modeler without having to apply them in Layout. The OpenGL in Modeler is passable that I didn't have to work in Layout to see the immediate result.

Aaah, just reread what you meant — yes a pain — to have to change the texture area and then hop between both apps to see the correction.

zapper1998
07-29-2012, 09:40 AM
i like modeler & layout as they are.

I like names on buttons to jog one's memory when i forget a shortcut (getting old!). I would take a rope it they changed the interface to an amateur eye candy layout. At least there is one company left that has sensible & efficient interface, but a few tweaks would help.

Would like to see more cores used!



ditto

rcallicotte
07-29-2012, 09:47 AM
The cool thing about is it could be unified and still separate. All sorts of technology in the software world allows for separations that could easily accommodate a generic workflow with tabs (like Modo) or even cooler ways like sliding panels that could be locked or moved about.

Anyway, I'm looking forward to the great minds who make this happen at Newtek. These people have been doing good solid work, regardless of the chaos around them, for years.

Dexter2999
07-29-2012, 10:18 AM
And by the way Philbert, I wasn't saying "follow the herd" any more than you were saying "let's be arbitrarily different!"

Julez4001
07-29-2012, 12:13 PM
How about a step-by-step solution.

One responder had a 6 line reasons for unification whic added duplicating some tools in both but makes 4,5,6 solutions worse but as TrueArts Sensei says, you would still have two commands that means completely different things (ala "Move").

So would baby steps in adding immediate features that make sense:

Like LIGHTWAVE unifying tools:
LW 11.5 - ability to edit deformations with simple tools, enhance layer support via hub
LW 12 - camera in modeler for set extensions


---------------------

Personally I think Maya and Modo are hugely cluttered.
Separate allows more focus but I would like to have some unifying tools to take those caveats of having them separate, away.

Sensei
07-29-2012, 12:31 PM
Layout currently can run Modeler tools which are non interactive.

It can't run Modeler tools which are interactive AFAIK. There is no Numeric panel window.

Layout doesn't have a way to select points, edges and polygons. So, when user is in Objects mode, he must have a way to switch between Points, Edges, Polygons, Item sub-modes.

Adding these two things would allow 3rd party developers start making modeling interactive tools in Layout.

hrgiger
07-29-2012, 12:43 PM
How is this not true? a smaller program in memory is a smaller program in memory correct?

Well for one, in a lot of cases there are causes to have both programs open at once (jumping back to modeler to edit a mesh, morph, weight map, whatever....) So that negates the whole 2 smaller program argument. 2 seperate apps are going to be a larger footprint then one unified one.
Secondly, there's no reason that a unified application has to have a larger footprint then modeler or layout. CORE for instance used less memory then either modeler or Layout from what I remember.


Speculation. It could be handled with workspaces, if they do it that way and do it well. But you don't know that this would happen. Not all unified programs handle this workspaces thing very well. Don't get me wrong, like I said it could be done well.


Modo does it fine enough.

evenflcw
07-29-2012, 12:59 PM
One responder had a 6 line reasons for unification whic added duplicating some tools in both but makes 4,5,6 solutions worse but as TrueArts Sensei says, you would still have two commands that means completely different things (ala "Move").

That's only in Sensei's limited view on todays architecture, I guess. There is no necessity to have a different move tool for each different element type. All that is needed is recognition on what type of element is selected and a tool that perform the operation accordingly. Moving a set of points need not be different to moving a set of nulls or particles. All the better if the same tool then was the interface to move any of them. What that tool then does internally to make the magic happen is nobodies business as long as it works. It is pretty straight forward imho, and frankly I don't understand why Sensei (as a skilled developer) plays blind to the obvious (or we both misunderstood). NT just need to code the magic, and implement selection filtering similar to maya, where you can turn on/off selection of each specific element type. Because with more types in the same environment selection needs vast improvement if workflow is to remain smooth.

jasonwestmas
07-29-2012, 01:07 PM
The Hub isn't the problem but having animation tools only in modeler is a huge problem for me.

Sensei
07-29-2012, 01:07 PM
You're talking about "writing everything from scratch"..

I was talking about it from current LWSDK point of view.

What is send to Layout interactive tool? Nothing. Everything it has to do, it does inside of Up()/Down()/Move()/Handle()/Count() handler functions (which means changing envelopes only). There is no even "do it" function, like in Modeler Build().

What is send to Modeler interactive tool? MeshEditOp structure.

So what do you want? Get ride of Modeler's interactive tool, or get ride of Layout's interactive tool?
Which means nothing what is currently available will work with new system.

Honestly, I don't mind going to new system, as long as there will be customers..

From scratch you can write anything.

Philbert
07-29-2012, 02:14 PM
Modo does it fine enough.

Read what you quoted. I said there are some apps that do it well, but others that do not. Point being it can be done and can work if done correctly.

cresshead
07-29-2012, 03:02 PM
You're talking about "writing everything from scratch"..

s..

From scratch you can write anything.

it's not from scratch though is it?

...newtek have the CORE development platform remember...they pulled CORE as an app but retained it as a development tool according to their press releases after "CORE the app" was cancelled.

ShadowMystic
07-29-2012, 03:35 PM
How is this not true? a smaller program in memory is a smaller program in memory correct?
Well I usually work in the later stages with both Modeler and Layout open. HOWEVER, I agree with remaining separate. Having modeler on one monitor and Layout on the other is a comfortable workflow. For me, HUB works flawlessly and changes done to a model nearly instantly appear in Layout


Two separate apps, modeler with no camera view? Set extensions anyone?

Why can't you set your plate you want to model to as your backdrop like any other reference? This is a serious question.

ShadowMystic
07-29-2012, 03:48 PM
Well for one, in a lot of cases there are causes to have both programs open at once (jumping back to modeler to edit a mesh, morph, weight map, whatever....) So that negates the whole 2 smaller program argument. 2 seperate apps are going to be a larger footprint then one unified one.
Secondly, there's no reason that a unified application has to have a larger footprint then modeler or layout. CORE for instance used less memory then either modeler or Layout from what I remember.


IIRC Max has a larger RAM footprint than M&L combined on my PC. Plus it loads slowly. I have an EXTEMELY short attention span. There have been times where I want to experiment with a idea, lost interest in MAX and already started in lightwave before the AD splash BS was ready for me to work... This is with a i7 and 16GB of ram. Can't imagie it be any better with less.

cresshead
07-29-2012, 04:26 PM
IIRC Max has a larger RAM footprint than M&L combined on my PC. Plus it loads slowly. I have an EXTEMELY short attention span. There have been times where I want to experiment with a idea, lost interest in MAX and already started in lightwave before the AD splash BS was ready for me to work... This is with a i7 and 16GB of ram. Can't imagie it be any better with less.

correct: 3dsmax is incredibly slow at loading, however it's full of beta code for the last 3 releases as it's being re written from the inside out so...it's slow to load...i usually make a cup of tea, bake a cake and re paint my front door whilst it load up.:D

Darth Mole
07-29-2012, 04:36 PM
Q.A better question could be
WHY was LIGHTWAVE 3D conceived as 2 separate applications in the first place?

answer - memory limits on the amiga i believe is the reason for the 2 applications being created.

Nope. They were just separate apps. Allen Hastings created Videoscape - a rendering and animation application - while Stuart Ferguson made a modelling app called modeler. They were complementary apps but made and sold separately by Aegis. NewTek almost bought Sculpt 3D instead of Videoscape.

jasonwestmas
07-29-2012, 06:32 PM
I think I have to be drunk to read all that Oliver.

hrgiger
07-29-2012, 06:46 PM
IIRC Max has a larger RAM footprint than M&L combined on my PC. Plus it loads slowly. I have an EXTEMELY short attention span. There have been times where I want to experiment with a idea, lost interest in MAX and already started in lightwave before the AD splash BS was ready for me to work... This is with a i7 and 16GB of ram. Can't imagie it be any better with less.

You couldn't have picked a worse application to compare a memory footprint to. Even though it is being rewritten, Max has been very well known for being bloatware and full of crap.

Ivan D. Young
07-29-2012, 07:21 PM
I think the best solution is still to have the two apps seperated for now. Layout continues on the current dev path. Then they will build Modeler in something else, either Layout striped out with Modeler inside or Core with Modeler inside. Get that working, Rebuild all the tools, and at a later date insert all of it into the same app.

This solution is probably most likely or at least some variation of that.

A gutted layout built as a Modeler gives the ability to incorporate lots of the ability of Unified app without have to cram it all in there now. lots of things need to be worked out before that happens. But the idea is that the foundation that you build on is the same in Layout and Layout/Modeler. You get cameras, you get the exact data interchange, you switch from object files to scene files and all that kind of stuff.

alexos
07-30-2012, 02:37 AM
Advantages:

a) everything the other guys said, and
b) it would shut some people up.

I like b).

ADP.

zardoz
07-30-2012, 03:06 AM
lol alexos.

Honestly I don't care if it's unified or not. I wish I could have some functionalities in layout like moving points and painting weight maps.
At work we model in different packages and render in another (lw, max or xsi) so for my/our workflow it sin't very important.
I'm used to model in one package and render in another.
But I guess modeler could be some kind of 'isolation mode' in layout. of course keeping the camera and animation.

dsol
07-30-2012, 04:26 AM
I'm amazed there's even a debate about this. It *has* to become a unified app, since otherwise some of the most useful uses for 3D software in VFX which require camera-based modelling (such as geometry projection and set extensions) are virtually impossible to implement in a way which is not obfuscated and/or clunky.

I think the problem is, some people think that in order to become a unified app, Lightwave has to completely throw out it's existing workflow and start making scenes + objects monolithic binaries. This is not the case - and it can be logically solved by supporting nested referenced scenes for those who want to keep assets separate from the main project(s).

Of course, if this is the case, then it also makes complete sense to create a unified file format (probably based on Collada) capable of containing all the data currently supported by the old multiple formats.

The nice thing about this workflow is that "objects" - single entity scene files - can contain lights, animation, scripts - even textures! - and can be dropped in ready to go into new scenes, and you won't need to worry about overwriting data in them if they're used in other scenes as changes can be applied as overrides and deltas (which are stored in the parent scene).

Of course, "bad" artists will probably just chuck everything into single monolithic scenes (and they should be allowed to if they want!!) but by careful design and some gentle nudging the theoretical unified Lightwave should encourage the creation of modular scenes with all assets separated cleanly. A bit like eternal CSS in websites, to use one analogy.

I've already written up some thoughts (and done some UI mockups) of how this could work in practice, but it's in the former CORE area. For those who have access, check it out here: http://forums.newtek.com/showthread.php?t=103727

geo_n
07-30-2012, 08:07 AM
I'm amazed there's even a debate about this.

You're amazed, I'm shocked, saddened it even exists, meanwhile people at Lux are rofl about this thread. :D
There's no need to jot down the advantages. Someone won't understand it unless they used something else for a few months seriously for a real project not some test run.

MrWyatt
07-30-2012, 09:34 AM
I'm with Oliver on this one. F* unifikation. Space battles don't need it.

dsol
07-30-2012, 09:40 AM
I'm with Oliver on this one. F* unifikation. Space battles don't need it.

Space battles would benefit enormously from the linked referencing I talked about before. After all, don't spaceships generally have lights attached to them for engines etc. Having a unified format means you could set up a default actor scene for each type of craft, then link them into a larger master scene.

Plus, don't you think it's about time we broke Lightwave out of the space battles niche anyway! (I kid, I kid - I know it's used on other shows... but you know, the majority are....)

zardoz
07-30-2012, 09:42 AM
well, I've used max and xsi in a few projects so I know what I'm talking about and what I'm saying is that I understand people who want it unified and people who don't want it.
If we had some of modeler functions in layout like weight painting, editing points etc, people wouldn't even ask for it. And everybody should accept other people's opinion, as I accept yours.

MrWyatt
07-30-2012, 09:46 AM
Space battles would benefit enormously from the linked referencing I talked about before. After all, don't spaceships generally have lights attached to them for engines etc. Having a unified format means you could set up a default actor scene for each type of craft, then link them into a larger master scene.

Plus, don't you think it's about time we broke Lightwave out of the space battles niche anyway! (I kid, I kid - I know it's used on other shows... but you know, the majority are....)

Noooooooooooooo. :cursin:
unification sucks. separation rocks.
I will from now on refer to myself as separatist.
all hail Vader.

wyattharris
07-30-2012, 01:08 PM
Pardon my questions but I have limited experience in other apps other than ZBrush.

So do they save objects and scenes as one file? Or do they each (3DS, Maya, Soft etc.) have their own method? I was mostly curious as to what the advantages of such a method would be but DSOL did a good job of explaining it. Still, seems to me that having the files separate offers more advantages than having them as one file. But then again, like DSOL said, if you can save a complete scene type format that is just the model and then reference that in the scene, that sounds pretty good.

I do like being able to catalog my models separately from the scenes.

However it goes down, this sounds like a lot of retraining. Sigh, I hate change but I'm sure in the end it will be a good thing.

jasonwestmas
07-30-2012, 01:42 PM
Some packages have a model format and a scene format. Just like zbrush or softimage. Yet they are a single environment.

VonBon
07-30-2012, 05:30 PM
I'm with Oliver on this one. F* unifikation. Space battles don't need it.

:lol:

OnlineRender
07-31-2012, 06:05 AM
Pro Unification but I would rather see modeler get spanked up first ...

50one
07-31-2012, 06:19 AM
Where do you think the modeler will be in say 5 years time, cause that's how much it will take to merge both apps - when we consider what Newtek is doing now.
I would rather see them releasing core, with limited toolset and slowly adding ret of the stuff, rathr than focus on unification in slow steps, while the core version is there somewhere used as a donor app.

Let's assume I'm bulding a racing car, but i've got one car which is quite good, other one is stock ford fiesta and an incomplete f1 car in the garage, now what's the point of merging first two using the parts from the third one, if the main goal is to get the f1 car working?

silviotoledo
07-31-2012, 06:41 AM
Unification means rewrite all the modeler tools to do each parameter animatable. It also means a better core under to support such capabilities.

It is necessary, but there's two ways for doing that:

1) Complete rewrite of the software = CORE, it was abbandoned
2) Incremental = gradual substitution, the way it's going actually

In my point of view Lightwave will never be completelly connected without rewrite, but once XSI needed 6 years with a bigger team and more technology access, lightwave will not do it in less time and community will complain about. That's what happened with CORE.

On my opinion, I don't need a perfectly connected Lightwave for doing my job. Of course I would preffer, but this is out of reality. So I don't need complete integration. I need integrated only parts of the software such as:

Camera in Modeler
Weightmap paint in Layout too
Hability do model endomorphs in modeler with bones posed in Layout
Sculpt tool ( both modeler and layout )

and some new tools like the ones bellow would be aceptable for Lightwave 12:

Mocap
Retarget
Layer Animation
Layared Deform System ( Stack )
Nodal controls ( but not only nodal )

But these are the tools I miss actually.

In a newer future I will miss a lot of parametical tools ( Like ICE ) once computer graphics is always in advance.

dsol
07-31-2012, 06:42 AM
I thought the point of the new direction (since CORE as it stood was set aside) was to continually upgrade/swap out the guts of Layout until it eventually became CORE - or its equivalent. This changeover is already visible in LW11 to a degree with the inclusion of Python scripting, but I suspect LW12 will be the one to really showcase the Core-ness of the new Lightwave.

EDIT: Silvio beat me to it!

I'd also add full Undo history support and modifier stack to that list...

Chazz
07-31-2012, 06:52 AM
Why can't you set your plate you want to model to as your backdrop like any other reference? This is a serious question.

Without accurate camera information, it's not going to match.

jwiede
07-31-2012, 10:18 AM
NT stated unification is coming, it will take time.
Just out of interest, what are you citing as Newtek's statement that unification is coming? I only ask because while I've seen statements that Newtek intends to deliver "the same benefits" as were being associated with CORE over time, in the ones I've read the phrasing was always a bit ambiguous regarding unification. If there's been a "Powers Roadmap Era" statement which explicitly committed to a unified application, I would be interesting in reading it.

hrgiger
07-31-2012, 01:02 PM
Just out of interest, what are you citing as Newtek's statement that unification is coming? I only ask because while I've seen statements that Newtek intends to deliver "the same benefits" as were being associated with CORE over time, in the ones I've read the phrasing was always a bit ambiguous regarding unification. If there's been a "Powers Roadmap Era" statement which explicitly committed to a unified application, I would be interesting in reading it.

I could be wrong but I think unification was actually mentioned in a Rob Powers interview. It said something about the unification of the modeling and Layout environments.
But I'll just stick with what I know for sure and that is that NT said they will deliver the same benefits with classic LightWave as CORE would have delivered. I kind of get the feeling though on that front that maybe they just mean key features as in Bullet, VPR, Python, etc.... I've yet to see any indication that they intend to add a modifier stack, complete nodal access, everything animatable, etc...

hrgiger
07-31-2012, 01:03 PM
I also remember Chuck answering a question about unification. In the same interview they mentioned that NT had a 3 year road map. When someone stated that LW would be unified within 3 years, Chuck corrected them and said that they had planned out for the next 3 years but that did not imply that unification would be done at that point.

GregMalick
07-31-2012, 02:35 PM
Personally, I'd rather see a robust Painting system in LightWave - in both Layout And Modeler. For painting textures and weightmaps in either Layout or Modeler. And by robust, I mean something designed along the lines of PhotoShop - masking/feathering/clone stamp etc. Not everything that's in PS of course but some nice basic painting/erasing stuff.

And some tools to tweak morph points in Layout would also be nice.


Effort along those lines would be better than unification of the same old app.

Hail
07-31-2012, 03:06 PM
why do people keep twisting and putting words into Robs mouth? where in this interview did he say unification was not a priority?
He has clearly stated that the lines they are threading along is going to result in a complete rewrite.

http://www.cgchannel.com/2011/06/rob-powers-on-lightwaves-three-year-roadmap/

jasonwestmas
07-31-2012, 03:15 PM
Well that's just it. . .there was never any clarity in the context of the future. . .and things change so much in this regard that it's worthless to even talk about it.

DogBoy
07-31-2012, 03:42 PM
Where in this interview did he say unification was not a priority?
He has clearly stated that the lines they are threading along is going to result in a complete rewrite.

http://www.cgchannel.com/2011/06/rob-powers-on-lightwaves-three-year-roadmap/

Yes, he clearly stated he believes that integration into a single app is the way to go (my emphasis to give NT some wiggle room ;) ). A year later, it looks like 11.5 is on the horizon, so maybe we'll see the first inkling of that move. Who knows?

DigitalSorcery8
07-31-2012, 03:55 PM
I just really can't believe that this is still being debated. :bangwall:

shrox
07-31-2012, 04:03 PM
I don't like change. Change brings demons.

DigitalSorcery8
07-31-2012, 04:11 PM
I don't like change. Change brings demons.

Bring on the demons! :devil:

jasonwestmas
07-31-2012, 04:18 PM
Where there is love, there is change; where there is change there is trouble.

DigitalSorcery8
07-31-2012, 05:16 PM
Where there is love, there is change; where there is change there is trouble.

And when there is no change there is stagnation.

VonBon
07-31-2012, 05:34 PM
and with the insistence of conformity, death is manifest for innovation.

erikals
07-31-2012, 05:52 PM
 
also, please fix >


Lightwave idea - Display correct Object 1
http://youtu.be/FUM0voF-3u0

Lightwave idea - Display correct Object 2
http://youtu.be/eFXJyhJJEts


can get quite annoying...

 

silviotoledo
07-31-2012, 09:26 PM
I vote for a unification between Maya and Lightwave :).

If this is not desire too much :).

jasonwestmas
08-01-2012, 06:46 AM
I vote for a unification between Maya and Lightwave :).

If this is not desire too much :).

well that is more desired than creating a maya Junior imo. :)

Snosrap
08-01-2012, 08:17 AM
Why can't we have both! Those that want uinification get it and those that want it separate can start another instance of the app. :thumbsup:

jasonwestmas
08-01-2012, 08:32 AM
haha. . .or just put some tools in both environments and not just one.

dsol
08-01-2012, 08:48 AM
Why can't we have both! Those that want uinification get it and those that want it separate can start another instance of the app. :thumbsup:

Yep, to paraphrase something I wrote in an earlier post here (http://forums.newtek.com/showthread.php?t=103727):

(written during the CORE era!)

The following graphic is a basic representation of Core, with two Core projects open. Since it's now a unified format, both these files are effectively the same format (collada), different data.
One "DemoObject01" contains a mesh. The other "DemoScene01" contains a reference to the other object, and is used as the environment in which we animate it.

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow01.gif

Note the tabbed interface. This is a design (and interface paradigm) I've shamelessly stolen from Google Chrome. What's important is that settings for that project are "compartmentalised" within that tab/file. The "Mode" popup on the right side only changes the UI layout of that project. When you open it, it automatically uses that mode. When you switch between tabs/projects like so:

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow02.gif

You can see that this project is set up to use the Mode "layout" and the UI is different accordingly. By doing this you can help structure your projects for maximum simplicity and focus. So if you need to make changes to a project file containing a mesh, it opens up with the correct preset mode automatically (unless you change it and save over that file!). This allows you to have a workflow that has many of the benefits of the old LW modeller/layout setup while having the flexibility to change modes on the fly if you need to add special attributes.

So, if you want to create a "master" scene, simply create a new Core project file and start importing (or rather referencing) other core files. That's a big difference from previous versions of LW - loading in these files always links them from the original file, rather than ingesting them. For organising it, well that might be just be another mode view setting. As was stated by Jay from the earliest days, the core node tree can be represented in multiple ways. Again, maximum flexibility - and user choice!

It's important to preserve the concept of compartmentalisation (there's gotta be a better shorter term than that!) between files at the UI level. Other people have suggested having "tearable" tabs, so here's a mockup of one. In this picture, the second tab has been torn off from the tab group and positioned to the right, creating an embedded dual-screen layout.

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow03.gif

I don't think this is necessarily a good thing. Note that there may be some duplication of tool icons in both views (each file effectively has it's own definable UI). It doesn't make great use of screen space as a result. A better solution might be of the type suggested by Mike Wolf, where torn off tabs create their own new windows, like this:

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow04.gif

Although there will still be duplication of tools in each window, to me this feels a lot more natural - and more "Lightwave". Alternatively, we could have a pop-up window for switching between open files. Jumping between them switches to their respective UI.

BTW, The file menu bar at the top is a standard system menu. It is unaffected by individual project file settings and instead serves as a fixed launcher for common commands.

dsol
08-01-2012, 08:55 AM
No! That can't work, because unified apps have an insane memory consumption. All the people I know barely get Max, Maya or whatever to start on their workstations. Imagine adding a box... impossibru! Having Modeler and Layout separate means that if there's a tool missing at a certain point in one module, just close that, open the other, do that operation, close that, open the other again - for full memory efficiency (workflow down the drain even more, but so what...). So much more convenient and memory saving. Or use the wonderful reliable hub (it gets better the more data it has to pass through whenever you switch focus!)... Layout, Modeler and Hub combined don't even use half of what Max needs! Which is great for me, as I need the other 11.8GB in my machine to have an instance of Battlefield 3 always running, 5-6 movies open in several players, Winamp, twice, all available webbrowsers with about 600 tabs each and another instance of Battlefield 3. Opening Max means I only have 10GB left, so I'd probably have to close Opera, which holds all the facebook tabs - unthinkable! Please NT, consider that before creating a unified RAM monster!

Or you could, like, close a few apps you're not using? :P Also, I think there's a least a couple of browsers out there that let you save your current tab lists. Unless you need them open at the same time 'cos you have multiple facebook personas like that crazy lady in "Catfish" ;)

Either way, I think it's fair to say you don't have typical usage requirements. Why would you run Battlefield in the background when you're trying to work in Lightwave???

I'm saying this in the jokiest possible manner: it's not "unified apps" that have an insane memory consumption. It's YOU :P

jasonwestmas
08-01-2012, 08:59 AM
No! That can't work, because unified apps have an insane memory consumption. All the people I know barely get Max, Maya or whatever to start on their workstations. Imagine adding a box... impossibru! Having Modeler and Layout separate means that if there's a tool missing at a certain point in one module, just close that, open the other, do that operation, close that, open the other again - for full memory efficiency (workflow down the drain even more, but so what...). So much more convenient and memory saving. Or use the wonderful reliable hub (it gets better the more data it has to pass through whenever you switch focus!)... Layout, Modeler and Hub combined don't even use half of what Max needs! Which is great for me, as I need the other 11.8GB in my machine to have an instance of Battlefield 3 always running, 5-6 movies open in several players, Winamp, twice, all available webbrowsers with about 600 tabs each and another instance of Battlefield 3. Opening Max means I only have 10GB left, so I'd probably have to close Opera, which holds all the facebook tabs - unthinkable! Please NT, consider that before creating a unified RAM monster!

HAAH! yes, life is all about saving memory and faster load times!! Forget finishing your projects on time with better workflows, that doesn't matter. Just charge the client more money. They'll come back for more just because you did such a great job and took your time with it. :D

MrWyatt
08-01-2012, 09:32 AM
No! That can't work, because unified apps have an insane memory consumption. All the people I know barely get Max, Maya or whatever to start on their workstations. Imagine adding a box... impossibru! Having Modeler and Layout separate means that if there's a tool missing at a certain point in one module, just close that, open the other, do that operation, close that, open the other again - for full memory efficiency (workflow down the drain even more, but so what...). So much more convenient and memory saving. Or use the wonderful reliable hub (it gets better the more data it has to pass through whenever you switch focus!)... Layout, Modeler and Hub combined don't even use half of what Max needs! Which is great for me, as I need the other 11.8GB in my machine to have an instance of Battlefield 3 always running, 5-6 movies open in several players, Winamp, twice, all available webbrowsers with about 600 tabs each and another instance of Battlefield 3. Opening Max means I only have 10GB left, so I'd probably have to close Opera, which holds all the facebook tabs - unthinkable! Please NT, consider that before creating a unified RAM monster!

Yeah, Tell'em Steve Dave.

Snosrap
08-01-2012, 07:58 PM
Yep, to paraphrase something I wrote in an earlier post here (http://forums.newtek.com/showthread.php?t=103727):

(written during the CORE era!)

The following graphic is a basic representation of Core, with two Core projects open. Since it's now a unified format, both these files are effectively the same format (collada), different data.
One "DemoObject01" contains a mesh. The other "DemoScene01" contains a reference to the other object, and is used as the environment in which we animate it.

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow01.gif

Note the tabbed interface. This is a design (and interface paradigm) I've shamelessly stolen from Google Chrome. What's important is that settings for that project are "compartmentalised" within that tab/file. The "Mode" popup on the right side only changes the UI layout of that project. When you open it, it automatically uses that mode. When you switch between tabs/projects like so:

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow02.gif

You can see that this project is set up to use the Mode "layout" and the UI is different accordingly. By doing this you can help structure your projects for maximum simplicity and focus. So if you need to make changes to a project file containing a mesh, it opens up with the correct preset mode automatically (unless you change it and save over that file!). This allows you to have a workflow that has many of the benefits of the old LW modeller/layout setup while having the flexibility to change modes on the fly if you need to add special attributes.

So, if you want to create a "master" scene, simply create a new Core project file and start importing (or rather referencing) other core files. That's a big difference from previous versions of LW - loading in these files always links them from the original file, rather than ingesting them. For organising it, well that might be just be another mode view setting. As was stated by Jay from the earliest days, the core node tree can be represented in multiple ways. Again, maximum flexibility - and user choice!

It's important to preserve the concept of compartmentalisation (there's gotta be a better shorter term than that!) between files at the UI level. Other people have suggested having "tearable" tabs, so here's a mockup of one. In this picture, the second tab has been torn off from the tab group and positioned to the right, creating an embedded dual-screen layout.

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow03.gif

I don't think this is necessarily a good thing. Note that there may be some duplication of tool icons in both views (each file effectively has it's own definable UI). It doesn't make great use of screen space as a result. A better solution might be of the type suggested by Mike Wolf, where torn off tabs create their own new windows, like this:

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow04.gif

Although there will still be duplication of tools in each window, to me this feels a lot more natural - and more "Lightwave". Alternatively, we could have a pop-up window for switching between open files. Jumping between them switches to their respective UI.

BTW, The file menu bar at the top is a standard system menu. It is unaffected by individual project file settings and instead serves as a fixed launcher for common commands.

Exactly - I think. :)

shrox
08-01-2012, 08:19 PM
...

http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow01.gif


http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow02.gif


http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow03.gif


http://www.digitaldistortion.net/stuff/lw/coreIdeas/multiWorkflow/coreWorkflow04.gif

.

I like this option.

Verlon
08-05-2012, 04:22 AM
So your reply is that everyone else does it so we should follow the herd?

No, Lightwave should not follow the herd. Lightwave should be trying to LEAD the herd.

Also, the herd isn't automatically wrong just because everyone is doing it no matter how insulting such a comment is.

Advantages of a unified app have been stated. Also note the line about "critical for setting up joint deformations."

Just because some haven't had issues with the Hub doesn't mean it has been so painless for everyone.

You say Workspaces will only solve the problem if done right. Is it your expectation that they would be done wrong (with Matt on the job?!)? At the most tacked on and usless level, it would just be the existing applications as workspaces in a unified application, wouldn't it?

Since you would be losing Hub and some of the shared resources (like separate UIs), a unified application would ideally be a little smaller than running both Layout and Modeler and the Hub simultaneously. Other than system resources, which I consider a weak argument when you consider the amount of resources in fairly modern systems, what advantages are there in NOT unifying the applications?

1. Development would be a bit of work
-- ok, but Modeler needs quite a bit of love anyway. I'll grant that it could break some plugins, but that is 'could' not 'would.'
2. Learning curve
-- only if it is different than the planned development for the separate applications (i.e. if modeler was going to combine extrude and bevel anyway, then that doesn't count. You would have had to learn that in modeler or Lightwave Unified).
3. Hotkeys
-- solved with workspaces (done right)

Are there any others? Compare that to the advantages of a unified application.