PDA

View Full Version : Could this be an answer to intergration?



wacom
05-25-2004, 07:10 PM
I'm sure this has been brought up before, but what about this:

Instead of the Hub being a little piece of software, that tries to connect modeler and layout, why not make it have the common (or what should be common) guts of Lightwave, and modeler and layout be "snap-able/dock-able" consoles of it?

I know we hate the word "Hub" here. So we could ditch that term in the end. The hub would have the main code for open GL, mesh deformation, rendering, texturing, etc that is or should be shared between Modler and Layout. This would give NewTek, and us, the advantages of having "separate apps" but also the advantages of having a single app.


Load up the main engine (aka hub). From there you can then decided if you just want to render out a scene, or open up one of the dockable (and un dockable for people with two monitors etc) consoles, either Modeler or Layout. This would not only save more on memory and other resources than the current Lightwave, but would use less than many totally all in one apps. Load as you go, when you want!

You could make as many "Modeler windows/viewports" as you wanted and dock them with as many "Layout windows/viewports" as you wanted. Since the core functions would already be in memory they would only take up a bit more resources.

In addition, since the resources are shared, that would leave room for things like a Layout "model select edit feature". Try and follow me here. This feature would be selectable by the user, but if enabled it would allow you to select a model/object in a scene layout window, and have it appear in its own space in a modeler window! Select the model in Layout, click on a modeler window and hit ****-A to center it and then go to town. No more worries about selecting the wrong vertex on two models, or dealing with layers like other one app apps have! All the clutter would be gone, and you could quickly edit your model and see the results at the same time in a layout window! Imagine how much faster you could work when editing a model for a scene.

When the core needed a “re-write” it wouldn’t be such an issue. If something small needed to be done for just modeler or Layout it could be addressed separately. If later it proved to be useful to Layout as well it could just be moved into the “core” or hub.


What do you think? Is this another one of my harebrained ideas, or is there not something to it?

Load up the main engine (aka hub). From there you can then decided if you just want to render out a scene, or open up one of the dockable (and un dockable for people with two monitors etc) consoles, either Modeler or Layout.

You could make as many "Modler windows/viewports" as you wanted and dock them with as many "Layout windows/viewports" as you wanted.

In addition, since the resources are shared, that would leave room for things like a Layout "model select edit feature". This feature would be selectable by the user, but if enabled it would allow you to select a model, object in a scene layout window, and have it appear in its own space in a modler window! No more worries about selecting the wrong vertex on two models, or dealing with layers like other one app apps have! All the cluter would be gone, and you could quickly quickly edit your model and see the resaults at the same time in a layout window!

Mylenium
05-25-2004, 11:38 PM
This certainly would be a way. It would eliminate lots of redundancies but allow to expand the feature set of both parts of LW. This is something like Lux does with Modo - independent components (Interface, geometry handlers, UV-texturing, different subdivision methods etc.) that are hold together by a main controller application. Also something like Maya would work where the main app can be largely controlled using the underlying MEL architecture but the important components are still hardcoded. Unfortunately we wont see something like that before LW v 10 or so, I guess.

Mylenium

sailor
05-25-2004, 11:59 PM
well i dont know nothing about design nor coding nor software engineering but i think as a Maya and LW user that before even thinking of how to split the softs and how to make them work together Newtek should come back to the root of the problem....memory efficiency is certainly importnat and not loading what is not needed is certainly very claeaver but before this we should make an effort and think of 3d as a global workflow...my point is: where does modeling stops and where does animation stops....the reality of this is that nobody knows....in Maya i have used keys to rotate objects into weird positions to model them aligned to world axis and moved back to key 0 ...this is animation or modeling? what about lattices.....should them be considered as modeling or animation tools ? another example...UV edition is in modeler but rendering is in Layout....why this?...i have also used the collision simulation in Maya to position bricks on a floor....is this modeling or animation? the benefits of having everything in an unified soft goes far far far beyond the eventual cons of memory efficiency and window cluttering.. as a conclusion: leaving to Newtek the final decision of what should be loaded as "modeling tools" and what should not is against creativity and basically against my personal idea of flexibility and productivity :)

and btw making this "small" changes like improving the hub or making a "main engine" that calls additional code when needed etc...well push the idea a little further and you have Maya ....and this is what long time users have been asking for a long time...nothing revolutionary just stantdard in the 3d world of today

wacom
05-26-2004, 09:25 AM
Originally posted by sailor
well i dont know nothing about design nor coding nor software engineering but i think as a Maya and LW user that before even thinking of how to split the softs and how to make them work together Newtek should come back to the root of the problem....memory efficiency is certainly importnat and not loading what is not needed is certainly very claeaver but before this we should make an effort and think of 3d as a global workflow...my point is: where does modeling stops and where does animation stops....the reality of this is that nobody knows....in Maya i have used keys to rotate objects into weird positions to model them aligned to world axis and moved back to key 0 ...this is animation or modeling? what about lattices.....should them be considered as modeling or animation tools ? another example...UV edition is in modeler but rendering is in Layout....why this?...i have also used the collision simulation in Maya to position bricks on a floor....is this modeling or animation? the benefits of having everything in an unified soft goes far far far beyond the eventual cons of memory efficiency and window cluttering.. as a conclusion: leaving to Newtek the final decision of what should be loaded as "modeling tools" and what should not is against creativity and basically against my personal idea of flexibility and productivity :)

and btw making this "small" changes like improving the hub or making a "main engine" that calls additional code when needed etc...well push the idea a little further and you have Maya ....and this is what long time users have been asking for a long time...nothing revolutionary just stantdard in the 3d world of today

I'm not talking about making small changes to the hub- I'm talking about ditching it.

And no, this isn't quite Maya. I'm not talking about having the main app, and then a bunch of plugins written in C encoded Lscript. That could happen, but the point is that when you load up LW you'd have a choice and that what gets loaded is mainly core workings. Going to render? Why load any of the modeler and layout extensions? Going to simply model? Why load up animation/layout extentions. Etc Etc Etc. This gives the user greater flexablity of resources, no two app loading, and no single, huge, bloated app loading if you can avoid it.
Do you know how small the rendering part could be in memeory once you cut out all the crap that loads with Layout?

As far as the modeling with "animation" tools I have thought of that. When you've selected an animated object you'd have the choice to model it in an animated form, or the base model. Frame zero (or your first frame) would always be pinned, and basicly the base model. You could edit on frame zero, and that would change the model for all frames, or choose a later frame and have interpolation, just like we "wish" we had now and like many other 3D packages.

prospector
05-26-2004, 02:53 PM
Hmmm
Hub as main engine.......

It Sounds like a slippery slope to integration...

ARRGGGGGGG

I can see the future threads now...

Well the hub only calls stuff when needed, so lets put a button that only changes screens for modeler and layout

then
quit making us change screens, it's only minor writing to be able to model in layout so lets do it and get it as 1 app

then
We need those icons for the menus because the words don't fit

What do we end up with?

The same as those other goofy programs.


Stand out..be different...don't be like sheep and follow the crowd.

wacom
05-26-2004, 04:36 PM
Look, please read what I wrote, I should have never said HUB. You people hear the word hub and start drawing conclusions. I just ment that right now the bulk of the program is in two seperate places...and the hub is the weak link. What I wish is that the bulk of LW's guts were in the Hub (you know, so stuff works right). Make the Hub a strong bridge, no a foundation, between the two instead of this weak link we have now. At that point it wouldn't be a hub, but the core of LW. Modler and Layout would still exsist as extensions of the core, and you could still use them independently of one another.

The whole idea of a dockable modler and layout is to facilitate both styles of working. Dock'em together if you like the way "one app" apps work and split them up and work seperatly if you like to work that way. We're talking flexablity here.

We want to retain the good parts of having LW be two seperate apps while getting aride of the problems it causes.

So again:

I'm not talking about the hub and I'm not talking about making LW like the other "one app apps".

The fact is that LW is going to change in the next release, maybe sooner, and I say we start this disscussion up again and keep it going so that we have some say it what happens. Otherwise we'll end up with the weak linked hub we have now, or worse...an app like all the rest. I don't want LW to be like the rest- I want it to be better than the rest.

If this thread degrades into a "don't put them together/make one app" battle I'm going to start a new thread. Lets try and think of some new ideas!

sailor
05-27-2004, 12:29 AM
wacom,

personally i think i understood you but whta i meant is that for a good soft design personally i first wanted to check what a nice workflow could be....so the question for you is simple...are modeling and animation/rendering tools stay separated in you scenario or not? the rest is just a matter of soft engineering so as a pote,tial user i'm not interested in how it is done but in the results....I cant only tell you what i didnt knew before using Maya that now i absolutely hate when using LW and viceversa....

what has now become a must for me when modeling is:

lights when modeling
animation tools for modeling
camera modeling !!!
checking morph targets (animation) and modeling to correct them
being able to run dynamics simulations to model (collisions, shatters , soft bodies dyns for ropes and chains for ex.)
and certainly many other situations i havent thinked of

quote: "and you could still use them independently of one another"

if your scenario allows this then cool if i still have to switch to another window, tweak the object in modeler then back to layout to check if its ok then back to modeler etc...then this is not my personal idea of a good design no matter how this is done and no matter if hub is rock solid or not ...it is much nicer to have everything at disposal eventhough i agree it is less memory efficient this way...

Nemoid
05-27-2004, 09:47 AM
I'm all for a one app structure, with the possibility to make a clever workflow eliminating some probs derived from what the UI of a one environment program brings.because this is only a UI task.

let's say i have all a set of tools at my disposal to get the job done, all in one environment, and then i organize those tools in layouts to organize my job.

so, if in a first time i want to focus to modelling tools, i'll design a layout with the tools i consider important for that job, having the possibility to use animation tools too. and show them on the fly too in my UI if i want to.

the same could be valid for animation. i could use modelling tools for animation, and more.

the concept would be : organize the one app, in compartments, in wich u can have every tool you want, because the environment is the same. you could have double buttons showing the same tool into a different compatment.
this means flexibility and organization at the same time.

then u could also simply switch from layouts to layouts of a compartment if u designed them and u could have the number of designs u want.

about the fact of having the hub developing as a common environment to host the tools of both Lw modeler and layout i dunno, because i'm not a programmer but the fact is that they actually are 2 different apps, with different tools so the job would be to bring those tools into an environment making them part of one app.

toasterhombre
05-31-2004, 09:08 AM
personally I would like to see one app with virtual desktops. In the Toaster sofwtare, there are 6 "virtual desktops". They basically let you "snapshot" any working environment and save it.

I can set up one screen for live switching, another for editing a 3rd for audio tweaking and one for charecter generator etc.

Why not have one app and you save preset desktops for modeling, rigging, animating, texturing, UV etc etc etc etc.

bloontz
05-31-2004, 09:52 AM
It sounds like what you are suggesting is basically how most modern apps are, or should be coded, using what is termed object oriented programming design. With OOP as it is commonly refered, you seperate any reusable code into what are usually called classes. This type of modularity makes larger applications much more manageable and stable. In a case like lightwave it would really help, the developers wouldn't have seperate blocks of code for say opengl between the two apps, it would be in a dll that was accessed by both layout and modeller. I must say that I find it hard to believe that the developers wouldn't already be moving in that direction. I also must say that I don't understand why the previous developers didn't move towards OOP a long time ago, it has been the standard practice for larger apps for a long time.

Exper
05-31-2004, 10:20 AM
A configurable drop-down for linking many LW Configs should help too...
you should fastly, without any app restart, switch from Modelling to Animating to any other custom Config in a blaze.

Then the HUB should be a sort of bridge between unified LW and external applications:
2D/3D Painters, Compositing apps, Scientific apps or any other custom ones!

Just my 0,000005 euro cent! ;)

wacom
05-31-2004, 06:43 PM
Originally posted by bloontz
It sounds like what you are suggesting is basically how most modern apps are, or should be coded, using what is termed object oriented programming design. With OOP as it is commonly refered, you seperate any reusable code into what are usually called classes. This type of modularity makes larger applications much more manageable and stable. In a case like lightwave it would really help, the developers wouldn't have seperate blocks of code for say opengl between the two apps, it would be in a dll that was accessed by both layout and modeller. I must say that I find it hard to believe that the developers wouldn't already be moving in that direction. I also must say that I don't understand why the previous developers didn't move towards OOP a long time ago, it has been the standard practice for larger apps for a long time.

Yes! I think there is a way to reduce or eliminate the redundant parts of LW, and still give people the work flow options they love. I hope that either NewTek is way ahead of us, listening us. What ever it is I'd like to see it have a tweak that makes it origonal and an advancement, not just an example of status quo.

wacom
05-31-2004, 06:49 PM
Originally posted by toasterdude
personally I would like to see one app with virtual desktops. In the Toaster sofwtare, there are 6 "virtual desktops". They basically let you "snapshot" any working environment and save it.

I can set up one screen for live switching, another for editing a 3rd for audio tweaking and one for charecter generator etc.

Why not have one app and you save preset desktops for modeling, rigging, animating, texturing, UV etc etc etc etc.

YES! Mix and match and make your own! That's what I'm saying. The user can then decide what is more important for a given situation. Need to model and animate a little...make it that way...need to animate and model a little...make it that way too...etc.

I just don't want everything to be loaded at once, only what is redundant, and let the user decide what needs to be loaded past that point. Click on a modual and it loads, save it to the workspace profile, and the next time you load it that modual loads up too. Each instance would be setup to load the moduals that you need at the startup of that workspace. Cool. Well if the VT has it I don't see why the LW team couldn't look over thier shoulders and see what to do...

wacom
05-31-2004, 06:52 PM
In addition:

This is kind of a seperate feature request, but I'd love the next version of LW to have something like an XTML type interface that can be retooled by a user. Think of how nice it would be to make the GUI act the way you want...and it might make it interface better with other apps etc. Might cause fewer GUI feature requests too.

toasterhombre
05-31-2004, 07:13 PM
The difference with VT is it is really a collection of several apps that can have their workspace configured. Not being a programmer I would think it easier to do the same with a single app.

The problem is right now there are two apps. I have always been a fan of LW being two apps for workflow etc. Having one app with assignable workspaces could be the answer. I love it on VT. . . . . . .maybe because I am the guy that requested it ;-)

titane357
06-01-2004, 04:02 AM
response to wacom.

Perhaps I am the only one that agry with you.
Look to softs like denebacad, or other, that have a 3d, draft,... sections, or like Maya (I think) : model, anim,...
Something like a hub that give specyfic environnements for modeling, animating,...
We would have still two programs with common elements like surfaces in the hub but don't feel them too separate like now.
We need more interraction between Modeler and Layout.
I'm right wacom ?

wacom
10-04-2004, 10:53 AM
Lets try and be creative to give NewTek some ideas that are BETTER than the competitor programs, not just as good.

I'm for intergration that gives us the best of both worlds:

http://vbulletin.newtek.com/showthread.php?t=23611

My idea was this: ditch the hub, and make all core functions run in a single modual. From this modual you can batch render (like SN) without loading everything, or you can load instances of the "LW modeler or layout GUI". From there you could designate diffrent windows to have either a modeler or Layout functionality. These would all reside within the "core" window when docked to it. Kind of like how viewports are now, but also like how toolsets are in almost every program like flash, photoshop, PSP etc. Click on a Layout window and you get a layout tool set. Click on a modler window and you get the modler tools. You could also lock the toolset to either the layout panel or the modeler panel, or make on unified custom toolset panel that works with each.

If you have only layout windows open you'll only get layout functions by default (and that will be all that is loaded besides the "core" program). Like wise if you have only modeler windows open you'll only get a modeler toolset. This saves on resources as you're only loading what you need.

To add to this would be this funtionality- say you have two layout windows (viewports) open and two modeler windows open. They are docked side by side in a quad layout fasion. By setting the modeler window to "current layout object" the modeler window will change to the current object(s) you've selected in you scene. Frame zero would act as a buffer where if you select a model in a layout window at frame zero it acts as the base model (kind of like the base model for morphs) and when you make modeling changes to it will change the model in all frames to match the base changes. However if you move to frame 1-X (X being any number of frames) you will be changing and animating the modeling you are doing to the model at that time. In essence animateable modeling/deformation.

In addition to giving us greater modeling an animation flexablity and speed this would also save on resources as you would only load a model once into memorey.
If you like the old way of working (one modeler, one layout) and you had a dual display setup you could just make one monitor have only modeler windows and the other have layout windows docked to each respective side along with their respectively docked tool panels. Save one with a layout preset of modeler and the other one of layout, or simple save them together as the default.

All plugins would funtion through the core so that modeling plugins could also be layout plugins etc. This would let EVERYTHING have the potential to comunicate.

Is this making any sense? I'm basicly saying this: man that old Amiga esk layout GUI is nice, but man there are so many new options for GUI's and loading programs now it's sick to have to use this same one with its limitations.

I don't want the maya's toolset- I want something better!

I'll stop for now...

Nemoid
10-04-2004, 02:20 PM
Well this surely could be done (hint : don't call the base platform hub!! it will disasppoint users :D )

btw surely a cool thing should be to have the app working divided into 3 main compartments, let's say model, animating and rendering with their own UI, but shared toolset.
so, obviously u could run Lw as it is now, - but with a huge difference : no double objects and textures in memory, nodouble tools projected for layout and modeler, so a more clever management of the enire set of files.

also, since the base little platform would manage all the content toolset wich could be nothing more than plugs working together all woul be optimized as well.

this will give u the possibility of running lw as u want. like now, or with a mixed UI organization, or make like u say modelerbe loaded when u want and waaay more things like mixed mod layout organization etc.

one thing to notice is that the toolset must be the same. so, toos have to be built as plugs managed by the base platform wich has to have a very opened structure and organization.


concerning apps like maya the complications they bring are not made by their structure, but from their UI and final workflow. nodal structure is great, but making the workflow of the app better for the dayly tasks is a great thing for final user.


the philosophy of a great app would be to give the user not only the power to make things , but also the ease of use of the toolset, with great intuitiveness.

this could bring for example an UI wich gives u the possibiliyty to get your dayly job done quickly as you would do in Lw, but having the power to refine LATER your job for complicated tasks.

example u could do your base texturing with an editor similar to the current texture editor, and then retouch your nodes with an appropriate editor
later when u really need whistles and bells, lets say completing your job from 80% (easy) to 100% (difficult) connecting , mixing and adding things differently.

u wouldn't take care so much of the nodes starting your job, but you would work with them for solving more complicated problems, just because when things become more complicated, even the way to accomplish those things can become a little more complicated than usual.

as u can see the best of both worlds. :)


p.s. and to have a good idea of what i'm talking about when i talk easy to use, just take a little look to Z Brush toolset...

TheDevil
10-05-2004, 08:10 AM
Just wanna post my devilish support for the above!!!! :cool:

lardbros
10-09-2004, 09:54 AM
I think this sounds like the right step, forward..... great idea guys/gals!

Still not sure how you would deal with the ability of using animated booleans or any other modelling tools? but its not the most vital thing... but would be VERY VERY useful! The only way for Wavers to animate modelling type tools is to "cheat" and use morphs/clipmaps etc! Just a pain when the actual tools are there in the first place!

Hope NT are reading this and nodding their heads!! :)

Nemoid
10-10-2004, 06:17 AM
well, things like animated booleans i think they could deal as they are put into other app maybe also with some realtime interactive preview, we all know that booleans are not always easy to do for every app though.

that's why we currently have to use plugs like booldozer or other free and even commercial plug wich get the job done.

into an integrated app, since animation and modelling could work together, even operations like booleans could find their way . u'll simply open a timeline into your modeler,(modelling compartment maybe?) on the fly, so that operations like animated modelling and animated boolean should work fine. booleans also depend from algorithms, though.
So a better working algorithm should be made too IMO.

carllooper
10-31-2004, 04:05 PM
As Lightwave evolves it has continued to maintain a reasonable ammount of backward compatibility. Plugins (and work practices) that worked in previous incarnations of Lightwave continue to work in subsequent incarnations. Of course there is a process of adaption. Some things don't translate or become redundant.

Now the best idea, keeping the above in mind, is not to integrate Layout and Modeler.

Rather - the solution is to evolve Layout - adding new functionality to Layout that reproduces the functionality associated with Modeler. In this way Lightwave's plugin interface does not need to be rewritten - it can just continue to evolve as it has done so. And work practices can evolve as they have done so.

Modeler can't be evolved to reproduce Layout functionality without a brand new plugin interface being created.

Carl

Doran
11-02-2004, 11:06 PM
Look, please read what I wrote, I should have never said HUB. You people hear the word hub and start drawing conclusions...


It's not the word "HUB" that most people object to; it's integration itself. Why does Lightwave need to be one console to compete or to be superior to other packages. I submit that it does not need to be integrated. Stealth integration is still integration from a resource and work flow stand point.

Here's are a few of the reasons I'm against integration.
First of all, I have no trouble with the HUB itself. It works fine for me .. and it's not in the way. Second, I enjoy having either Layout or Modeler run by itself to eliminate the overhead baggage a companion app brings in resource usage. Third, the segregation of the two is the historical identity of Lightwave. Fourth, clutter will occur after integration somewhere; it can't be helped. Plugins, config files, menus, or just the window look and feel is less cluttered or confusing when they are separate.

I feel the community would be better served if the integration assimilation association would just accept that Lightwave has two applications and instead concentrate on making great animation, models, plugins, learning and developing new techniques to write tutorials on... or even making specific feature suggestions instead of pretending that integration is a "feature" we need. :O)

Exper
11-03-2004, 02:26 AM
... and pretending we need new "features"! :(

Doran
11-03-2004, 03:37 PM
... and pretending we need new "features"! :(


:O) Don't read me wrong. I'm not opposed to new features or feature requests as such. But I question whether suggestions like, "can't we get rid of the Dongle" or "Newtek needs to do more PR" or "we need integration" are feature requests. These in my mind are not features.. and the whole point of this forum is "New Feature Requests".

carllooper
11-03-2004, 06:36 PM
I have no problem with Lightwave's current Layout/Modeller interface. No different from opening and closing any of the other interfaces. Modeller is for building objects and Layout is for building scenes. And the apps reflect the difference between these two things.

And really, as far as Lightwave's UI is concerned, Modeller and Layout are already integrated - through syncronisation.

However I'm talking about integration "under the hood" where it would be good to have modeller functions that lived within Layout's internal architecture.

This doesn't mean the UI needs to change. At the interface level this new functionality could occur under a different tab or in a whole new window for that matter. No clutter at all - just like it is now!

But within Layout's internal architecture, such reimplemented Modeller functions would have the benefit of the event driven system there. Scripts could take better advantage of these functions.

Nothing dramatic here.

Carl

Doran
11-03-2004, 10:25 PM
But within Layout's internal architecture, such reimplemented Modeller functions would have the benefit of the event driven system there. Scripts could take better advantage of these functions.

Nothing dramatic here.

Carl



Carl, maybe so I can better understand your point of view, could you explain what you mean by "event driven systems"? How would modeler bring this to layout? You aren't talking about procedural modeling applied to animation.. right?

carllooper
11-04-2004, 05:46 PM
Carl, maybe so I can better understand your point of view, could you explain what you mean by "event driven systems"? How would modeler bring this to layout? You aren't talking about procedural modeling applied to animation.. right?

Modeling functions that aren't just in response to user initiated events (as in Modeler) - but events such as time. Or collision events. Or texture layers ... whatever ... Event driven modelling. Scriptable. Keyframable modeling.

Of course, nothing is stopping anyone from already implimenting this in a third party plugin. I'm sure some already have.

Carl

Doran
11-04-2004, 06:57 PM
Modeling functions that aren't just in response to user initiated events (as in Modeler) - but events such as time. Or collision events. Or texture layers ... whatever ... Event driven modelling. Scriptable. Keyframable modeling. Carl

It's an interesting idea. Not many folks would have a use for this. I suspect that a plugin for modeller would be a good idea.. I'm not sure integration would necessarily bring these things about.

carllooper
11-04-2004, 07:59 PM
I suspect that a plugin for modeller would be a good idea..

The point is that a plugin for modeler can't do this.

Modeler's architecture, (at least from the point of view of the plugin interface), doesn't support event driven modeling. The reason is that there are no relevant events to support.

In Layout, on the other hand, there are many events to which modeling functions could be attached.

Consider how bones (in Layout) provide keyframeable control over object geometry. Well it's not hard to imagine modeler functions being keyframeable as well.

But this only makes sense in Layout.

Modeler provides a context for the construction of Lightwave objects and such objects are essentially static structures. So animating objects in Modeler doesn't make any sense.

The point is that the fine grain control one has over the geometry of objects in Modeler could be made available within the dynamic scriptable keyframeable context of Layout - either as a plugin or as a future feature of LW.


I'm not sure integration would necessarily bring these things about.

This is not necessarily "integration". Modeler can remain unchanged. Rather it is the creation of a second Modeler (it's functions) within the context of Layout.

This idea becomes "integration" only if (or when) Modeler is put out to pasture.

But if the traditional Modeler was to be put to sleep, the new (integrated) Modeler would have to reproduce all of the old Modeler's interface AND it would still need to reinforce the distinction between the dynamic nature of scene files and the static nature of object files.

The current system reinforces this distinction quite naturally. And I'm more than happy with the current status quo.


Carl

Doran
11-05-2004, 10:55 AM
Is this making any sense? I'm basicly saying this: man that old Amiga esk layout GUI is nice, but man there are so many new options for GUI's and loading programs now it's sick to have to use this same one with its limitations....


This is where you loose me. The UI is not Amiga-esk - it's Lightwave-esk; yes, this is how it was developed on the Amiga…. but it has been on the PC longer now than it was on the Amiga.

I like the separation. One could make the same arguments about the advantages of integrating Maya, Photoshop, Notepad, and Lightwave Modeler and Layout into one large module but I don't believe that any advantage would be worth it. Some would argue that integration of Internet Explorer into the Windows OS was actually counterproductive from a development point of view. It has in some ways limited our options and at the same time swelled the Windows operating system to unparalleled bulk..

Lightwave as one bulky assimilation to me would be inelegant and no longer Lightwave.

DragonFist
07-15-2005, 04:01 AM
This is where you loose me. The UI is not Amiga-esk - it's Lightwave-esk; yes, this is how it was developed on the Amiga…. but it has been on the PC longer now than it was on the Amiga.

I like the separation. One could make the same arguments about the advantages of integrating Maya, Photoshop, Notepad, and Lightwave Modeler and Layout into one large module but I don't believe that any advantage would be worth it. Some would argue that integration of Internet Explorer into the Windows OS was actually counterproductive from a development point of view. It has in some ways limited our options and at the same time swelled the Windows operating system to unparalleled bulk..

Lightwave as one bulky assimilation to me would be inelegant and no longer Lightwave.

I can appreciate your point of view in that I personally like Modeler and Layout separate. However, there ARE workflow issues that involve laborious back and forth motion from Modeler to Layout and back again (UV Editing come to mind first) that you are simply brushing off as nothing. You may have no issue with it and it is certainly being worked with at this time, but don't presume that because you don't have a use for such changes means that nobody else needs it either.

I think an OOP design could handle both sides of the issue. However, I don't have to have it be that way. But I definitely think that if the forced switching of apps to complete one action isn't addressed, Lightwave will lose ground. Personaly, I could care less if it is done via intergration or by having the tools of each app that are present in one but lacking in the other are placed in both and have that be that. I think intergration would be the easiest thing in the long run for Newtek as the development cycle no longer has two threads but one. But I'll take whatever I am given as long as I don't have to keep switching back and forth in order to model and texture and rigging, etc.

Let me do ALL of my modeling in Modeler and give me all the tools that I could possibly need to do so IN Modeler, including test renders and Fprime and on and on. Then I'll gladly switch to Layout for the scenes.

You asked in an earlier post why this keeps getting suggested. The above is my answer. And I feel that it is a pretty valid one. I agree that it could be solved other ways than intergration, but I am not too keen on the "I am happy the way it is so you have to be too" viewpoint.

Best,

Shawn