[arch4d]

title says all...

[gadzooks]

Amen Brother!

[JDHill]

It would be helpful if we were a little more specific about exactly what needs the ability to be 'undone'...such as object movement/deletion, material changes, etc.

~JD

[Kabe]

Specifically: Everything that changes any data.

Implementing Undo means building a general mechanism to handle user
input in a non-destructive way. There are a lot of implementations, but you
don't do that command by command.

This is no topic for sprayed on useability, and it's much harder to add it later than to design your app with it from beginning.

Frankly it doesn't bother me too much, as I don't work in Studio anyway.

Kabe

[arch4d]

@ JDHill:

what do you mean by "It would be helpful if we were a little more specific about exactly what needs the ability to be 'undone' " ?

every app just NEEDS undo and redo.

does anyone know any app without that ?
in most apps you can even set the number of undo steps possible.

can´t imagine why they forgot that when designing studio...
i really need that.

don´t wanna save the scene after every step i´ve done...

[Mihai]

It's true it's needed for some things, but the way Studio works, *practically*, an Undo isn't missed as much.

Mostly in Studio you are changing material settings and applying materials. Hardly a critical need for Undo in those areas.

What's missing is the ability to lock a camera so you don't accidentally start navigating with it, but it's easy to make a back up cam with one click.

If you accidentally move an object, just set its transform options back to 0,0,0.

[jdp]

Mihai, I don't understand why one can't have the needing of an undo in the material and texturing workflow too?

[JDHill]

arch4d,

What I mean is, there are many things which could be 'undoable', yet might not be considered necessary. For example, should we be able to undo every move of every camera, and if so, when panning or zooming, what is considered to be an 'undo step'? Things like that. We can change a material by drag & drop, which is pretty easy if you're grouping your objects, so...should NL focus put much effort into that type of undo? Should the material editor provide this function for all material parameters? Or, are we really more concerned with object movement/deletion type of changes?

And...I'm not so sure that it would be correct to say that they forgot it. I was pretty critical of the Studio UI in the beginning, but I've seen quite a bit of smart design gradually exposed in this UI as we went from RC1 to RC5. They likely have the necessary methods in there already to implement most types of undo functionality that we are likely to request.

The main point of my previous post was basically this: there are alot of pieces to this interface, yet only one (or a couple) buttons hooked up to any undo function. It would be most helpful, given a limited timeframe for development, if we could let them know exactly what we think the program should do if a user clicks that button at any given time?

~JD

[Kabe]

The main point of my previous post was basically this: there are alot of pieces to this interface, yet only one (or a couple) buttons hooked up to any undo function. It would be most helpful, given a limited timeframe for development, if we could let them know exactly what we think the program should do if a user clicks that button at any given time?

If they don't know what should happen on undo, then they should look
for another job. I mean it.

Writing an undo function is *not* done function by function, it's *not* specific
to certain commands. And as it is in the foundation of the framework, it's
really hard to hack it in later. In the Cinema SDK, this is a 2 line command in the framework, and you're ready to use it.

BTW: Yes, it is indeed necessary for material changes, data can be
changed there and no other method than undo will bring it back. It's
the feature nearly everyone has to use, even with most of the plugins.

Kabe

Kabe

[JDHill]

Well, Kabe, that's nice in theory...but it actually does have to be determined at some point in time, just what will subscribe to the service, and how. To reiterate:

For example, should we be able to undo every move of every camera, and if so, when panning or zooming, what is considered to be an 'undo step'?

What do you suggest? That every event raised, be pushed? How annoying would that be? Undo, as a paradigm, has never been, and can never be generically defined. And, as you are so apt to point out, we have no SDK. Why? We are still in pre-release, and the framework is obviously still being defined...I seriously get annoyed by the way people throw around framework, API, and SDK interchangeably on this forum.

And...thanks for the specific request for material changes undo...these kinds of helpful suggestions are exactly what I was referring to. Excuse my tone, please...I was originally only trying to add a helpful suggestion to the original post.

~JD

[Kabe]

What do you suggest? That every event raised, be pushed?

Normally it's every user action that permanently changes data, but this
really is the job of the engineers, not ours.
You can't make too much wrong with it, but of course you need some
inside knowledge. I won't write specs for a company that don't use it
anyway.

Undo, as a paradigm, has never been, and can never be generically defined.

I'm too lazy now to look it up, but there are certainly a couple of papers
that take that issue to great depth. There is a number of applications out
there that even use this feature. It's not a lack of spec that is responsible,
it's just a lack of implementing any undo mechanism.

And, as you are so apt to point out, we have no SDK. Why? We are still in pre-release, and the framework is obviously still being defined

Well, the SDK is a completely different kind of thing and has *nothing* to
do with the Studio Undo mechanism. And we don't have an SDK because
we're not named Rossmann (not too belittle him btw.)

...I seriously get annoyed by the way people throw around framework, API, and SDK interchangeably on this forum.

I agree on that, and while API and SDK are widely interchangeable,
framework can mean at least half a dozen diffenert things in M~R context


Cheers

Kabe

[Mihai]

Mihai, I don't understand why one can't have the needing of an undo in the material and texturing workflow too?

Well, ok give me an example when an Undo is useful when tweaking material settings and applying materials?

XSI has a very good Undo feature (camera movements are handled by separate Undo feature using Alt button). But I must say I have yet to use the Undo feature when tweaking material settings or applying a material to an object or group of objects.

It's just the way I work, but I'd like to hear a practical example where it would be useful to have an Undo in these cases.

[jdp]

Ok then, let me know if I understand correctly.
first of all you said that:

Mostly in Studio you are changing material settings and applying materials. Hardly a critical need for Undo in those areas.

and this is of course your assumption, even if you always say that a load of users, without per package plugin, needs studio for doing their texturing and so on (which is more than correct in my opinion, for the record). for this kind of users an UNDO function is a key issue for sure, because it involves a bunch of tasks per session.

then you said:

But I must say I have yet to use the Undo feature when tweaking material settings or applying a material to an object or group of objects.

I don't know if this is a correct workflow or not for you, but it's exactly the way I go most of the time. Why? because I am lazy and I like the most going back several time undoing changes instead of typing everytime again the same settings I typed before (I hope to have been clear enough).

What I learned at school in my very entry level interface design class (I am an architect, not an interface designer), is that you have to keep in mind that users have to think the less: they want to do tasks, not improve their skill with your interface. the best interface is the one you won't never need to learn. Undo is way more simple than any other workaround.
book suggestions: Jef Ruskin, "The Humane Interface: New Directions for Designing Interactive Systems." and Steve Krug, "Don't make me Think".

I swear that I am not trying to belittle you, and I am still a strong supporter of the software, but I, again, don't understand why are you getting so harsh. If I am, sorry, It was really not my intention.

ps: in 3dmax there is a separate undo function for ordinary views (ortho and perspective), besides camera movements are affected by the undo functions (since they are also objects, not only views).

[giacob]

how can be mantained that an undo option is not needed ? cant belive that
( like this is ok? always at work mike... good moorning )

[aitraaz]

heh ...undo sucks. Let's skip this one and move on...