PDA

View Full Version : Calling all old hats! Remember any ancient and persistent LW bugs?



eblu
05-03-2007, 10:11 AM
a co-worker and I were talking the other day, and we started reminiscing all of the really big gotchas in LW, and what version they were in. It was sort of like comparing battle scars.

this conversation developed from a my recent post about a graph editor bug, which was not fixed through several generations of LW. We LightWavers tend to work around bugs and develop habits that keep us safe from them, and so we never test for them, never report them, and they never get fixed.

I think there are more of these gotchas, but I have habits that keep me from identifying them.

So, I'd like to compile a list of these major gotchas, that made you Stop using a feature, find a workaround, or develop a work habit that otherwise you would not have done? let me know the gotcha and the version (versions) in which it was a problem.

drclare
05-03-2007, 11:05 AM
IK Boost! I don't know if it was/is a bug, or just a poorly implemented feature. In version 8.0 IK boost is so slow to respond that when you move a goal, it takes LW several seconds to catch up, and by that time your model goes all out of whack. So I just stick with the old method of riggigng characters. It's not a huge deal, the old method works fine, but it's one of those things where we got a great sounding new feature, that would allow you to work faster and more efficiently, only to have to basically ignore that it even exists if you want to work at all.

Greenlaw
05-03-2007, 12:11 PM
Hi,

Not really a bug, but there is one little LightWave thing that's been bugging me for years. In Modeler I often find it helpful to switch between Grid Snap Standard and Grid Snap None, and it's a hassle to have to go into the Display Options panel and switch modes through a lister. This really needs to be a feature that you can toggle with a single keystroke.

It's become a ritual for me to ask for this feature every few years, so I'll take this opportunity to ask for it again. Pretty please, Newtek? :)

DRG

eblu
05-03-2007, 02:28 PM
just found one thats been around since at least 7.5 and I had forgotten because I learned Not to use it! Texture guide. it crashes frequently! PC AND Mac!

HenkDawson
05-03-2007, 02:36 PM
Umm.. The HUB

Weepul
05-03-2007, 03:36 PM
Ofttimes, if one accidentally does something computationally intensive in Modeler (or even on purpose sometimes), it will generally hang with no way to cancel, requiring you to either force-quit it or wait until it crashes itself. Better handling of failing to do what the user asks plus prevalent awareness of a cancel key (generally "escape") would be a nice added measure until the day when there's nothing Modeler can't do. :D

eblu
05-03-2007, 03:56 PM
weepul, greenlaw...
great ideas.
I suggest you put them in the feature request forum.

I'm looking more for bugs that we all love to hate... like the old Quicktime bug in V. 7 ish. you couldn't save to a quicktime, Layout would crash. Its been fixed since then, but it was BAAAAAD

toby
05-03-2007, 04:13 PM
The MULTI-SELECT bug! Select a few polygons in Modeler and delete them, five minutes later you notice holes on the other end of your model.

Also the modeler display setup and backdrops that revert back to default if you change the viewport layout.

kopperdrake
05-03-2007, 06:11 PM
I'm with Toby on that one - spent ages modelling a hand only to find the head all mussed up. Saying that, I can't seem to replicate it in version 9 :D

jameswillmott
05-03-2007, 06:46 PM
It was finally fixed in 9 (I'm sure it can be replicated but it's not easy anymore!)

kopperdrake
05-04-2007, 11:05 AM
Oh :( That's like losing an old friend. A smelly old friend, but an old friend nonetheless. Modelling will never be the same!

My favourite persistant bug at the moment is the surface editor defaulting to the first surface of the first object when you save an object out.

eblu
05-07-2007, 09:46 PM
maybe not a bug, but the selective undo... man that kills me.

Chilton
05-07-2007, 09:52 PM
Hi Eblu,


maybe not a bug, but the selective undo... man that kills me.

Please elaborate! I am confused and frightened by your post--any bug that causes the sudden death of the user should at least get an asterisk with a footer note in the documentation.

-Chilton

kopperdrake
05-08-2007, 03:37 AM
Don't Walk Into The Light Eblu!!!

eblu
05-08-2007, 07:09 AM
ok, elaboration:
layout and undo are not friends. this comes from a 3-d architecture that is older than undo is. so, as lightwave has matured over the years it has had to really work hard to get a remedial amount of undo support.

some things can be undone, while others cannot. almost all plugins deal with undo in whatever way they feel like (leading to inconsistency). the graph editor for instance, has its own undo.

Users don't ever get used to this, its counter intuitive to everything they ever learned. Everything should be undo-able. for instance, time scrubber changes, backdrop changes, not just the things that are on some arbitrary list at Newtek headquarters.

this speaks to a gigantic pet peeve I have w/ Lightwave. theres no modern plumbing for scripting or undo. every action in Layout can easily be undone, its just that the ground work was never laid, deep enough in the app for a modern undo system, or a modern scripting system... which are essentially the same thing if you set it up correctly.

I've been making requests for this sort of thing for just about 7 years now, once or so every few months, finally giving up on Newtek about a year or two ago.

go get this:
http://www.amazon.com/Cocoa-Recipes-Mac-OS-X/dp/0201878011/ref=pd_bbs_sr_1/103-6789027-6840642?ie=UTF8&s=books&qid=1178629663&sr=8-1

and read what the master chef Bill Cheeseman (from the real story behind "a Civil Action") has to say about undo and scripting.

BazC
05-08-2007, 07:41 AM
Image viewer extending off the bottom of the screen on big renders. Aaaaarghh!

gatz
05-08-2007, 12:43 PM
Audio is LW most worthless "feature." As it works now I just don't see the point. It can't be scrubbed reliably, it isn't possible to nail ques. Even in preview the sync slips so that it's different every time it's played. Does this qualify as a bug or quirk.

rg

eblu
05-08-2007, 01:04 PM
gatz. I think it does. I think it does. (qualify)

toby
05-08-2007, 10:15 PM
It was finally fixed in 9 (I'm sure it can be replicated but it's not easy anymore!)
By Jove I think it is fixed! (Multi-select bug)
I opened the same model I had lots of problems with ( a car interior, trying to select parts of the interior from inside, with polygons behind the view ) and couldn't make it happen even once. Sweet!

toby
05-08-2007, 10:26 PM
Great thread eblu! Good to keep these things fresh until they're killed.

But keep in mind that all apps have selective undo, and it's debatable what should go on the stack or not - in Max and Maya I run into things all the time that don't undo - but I do agree that LW is way behind, maybe this rewriting will make things possible. I am getting tired of having to reload a scene if I delete something accidentally. I've gone for a long time with my training from Photoshop 4 on how to work with one (or no) undo, it's getting old!

Baz, gatz, agreed!

G M D THREE
06-25-2007, 10:09 PM
In 9.2 there is a error message popping up every time I open a scene on a different machine than originally created, saying something like: RGB output directory not found. I found it highly annoying as it is very dysfunctional. This should appear when you hit f10 and it can't find the output directory not when you open a scene. Therefore it's on my bug list.

///

byte_fx
07-03-2007, 04:46 AM
Apart from the others mentioned - especially the one about the audio - the 'sticky' Kelvin color picker.

Didn't have much time to play with the lw 9 demos but at least up to then it defaults to 6000 K every time it's opened.

Makes it hard to do a minor tweak to color settings.

As an aside - some sort of handle showing current position would also help.

byte_fx

eblu
07-10-2007, 07:15 AM
i got one. for all of history, Lightwave has failed miserably to follow simple window behavior guidelines. from using the wrong kinds of windows, to having their own, slightly less robust window management routines. Lightwave is known for losing utility windows behind the main window, for hiding and Not hiding palette windows at the wrong times, for having buttons (like minimize, and maximize) that don't work, for not responding properly to os level events... like messages from the os to become the frontmost app.

there are EASY ways to fix this. have been from day one. its terribly frustrating to live with.

Cageman
07-10-2007, 07:24 AM
Progressbars with Cancel-option!!!

Shifting alot of keyframes freeze LightWave and you can not tell if i has hanged or if its still working.

EDIT: I didn't notice this was Mac-specific forum.. *lol* But I guess this is true for the Mac-version as well... ?

Darth Mole
07-17-2007, 09:53 AM
That bloody selection-tab thing. You all know: click into the fifth field on a panel, enter figure, hit tab, enter figure... first field is now changed with no undo. Sonofabitch.

Chilton
07-17-2007, 12:32 PM
Hi Darth,

I think that one is fixed in the UB. Of course, we can't discuss that here. But if anyone here wants to discuss this in the UB forum, feel free!

-Chilton

tonyvdb
07-18-2007, 08:33 AM
This is going way back but in version 5.0 (the last version for the Amiga) if you switch between the modeler and the layout screen more than about 5 times you would need to restart LW as it would become very unstable.

Chilton
07-18-2007, 12:30 PM
so is this for pc and mac here?

Mac specific.

-Chilton

Chilton
07-18-2007, 12:30 PM
Hi Tony,

That should be gone. Does it still happen?

-Chilton

tonyvdb
07-18-2007, 02:34 PM
Well (this is almost embarrassing) I'm still using version 5 on the Amiga along with the Video Toaster Flyer and due to the fact that that was the last version done for the Amiga there was no fix made that I know of.

Chilton
07-20-2007, 05:26 PM
Hi Chunderburger,

The Mac version of LW fell behind the PC version in some past releases. We're trying to remedy that, and this thread is one tool we're using.

Additionally, there are some Mac specific things that make sense on the Mac platform, which won't make it into the PC version. By the same token, I'm sure there are some things in the PC version that won't make it into the Mac version.

We're trying to deliver a consistent cross-platform experience, while taking advantage of platform specific capabilities when possible.

-Chilton

eblu
07-27-2007, 08:37 AM
i got one.
displacement maps.
I am doing a flag animation, and I'm using the ripple procedural to give the flag a natural displacement ala waving in the air.

but... just applying the ripple procedual in the displacement panel, displaces the Whole flag, I want to dampen it where its attached to the pole, so I go into modeler, put a weight map that falls off from the pole, and then in Layout make a gradient that uses the weightmap... and then I'm stumped.

I'm no dummy. I know that the displacement on the flag is the value of what is derived when the layers of textures are added together.

for instance... I'm displacing on the z axis, and I have two grey images, being used for the displacement. the one on top is 50% opaque, and so the value of the displacement will be an average of the two grey colors, scaled against thier respective 3d values.

so... I want to dampen my ripples by obscuring the value of the ripple with a gradient that falls off to transparent. the completely opaque portion of the gradient will completely obscure, and replace the value of the displacement, and fall off to the ripple value. This is what the math says will happen, it is Not what happens. the gradient completely breaks the displacement, completely replaces it.

in a move that is completely counter-intuitive, Newtek has hobbled the displacement sub system, they have rendered the xfer modes for layers worthless in this context, and damaged my muscle memory. been that way for years. my co-worker is looking at me like I'm an idiot because I expected it to work. Which I have every reason to expect.

eblu
08-13-2007, 07:46 AM
window focus.
Lightwave is a platform independent entity (since the loss of the amiga of course), I have a lot of respect for this, and the independent spirit that comes from being platform independent. But... I am extremely frustrated by the approach Newtek has chosen with regards to high level integration into the os.

the problem is one of Too much independence. Newtek has a defined set of window (and if truth be told, Text box as well) behaviors that are impossible to manage through any os except for the amiga of years gone by. Instead of accepting this fact and "bending in the wind" Newtek simply takes the bull, by the horns and tries to force each OS to do what the amiga used to do.

these behaviors open connections to legacy code in the mac, which is slowly melting away, each update of the os changing things or fixing bugs that Newtek relied upon for their hacks to work.

Newtek has to maintain and develop these window behaviors at a very high cost in man hours, without any reasonable increase in functionality. It is actually a few steps backwards. Newtek doesn't have as many engineers as Apple does. None of Newtek's engineers focus on Windowing technology, UI behavior (at THAT level) or the Mac workflow. So the routines they built are not as polished, are not as familiar, and are actually pretty buggy.

its a pet peeve of mine when any kind of sub-window takes focus (captures the typed output from the keyboard) by just being opened.

Its another pet peeve when a utility window has a title bar as big as the document window.

also when a utility window falls behind the document window.

these are all problems due to Newtek writing its own window handling protocols. Bug-ridden, protocols that are simply unnecessary.

Newtek could cut a gigantic list of Mac bugs Out of LW, simply by removing the window protocols and letting Apple's default window classes do the work.
But Not in carbon. You'd Have to use Cocoa. And I have heard all of the objections to this for easily 8 years, and none of them wash.

replace the windowing system with standard Windows. Let apple's robust windowing protocols become your windowing system.

And, throw your poorly designed and highly antiquated Text entry system into the woods, use apple's NSTextField (a class in cocoa, which can easily be programmatically generated) or a subClass thereof.

no more will we be stuck with a poor man's windowing system, or text boxes that display nothing, text boxes that forget that they are in focus, or simply redirect your text input to another box.

Chilton
08-13-2007, 10:27 AM
Hi Eblu,


window focus.

its a pet peeve of mine when any kind of sub-window takes focus (captures the typed output from the keyboard) by just being opened.


I may be taking this out of context, and if I am, I apologize. But this behavior (forefront window always gets focus) is the correct behavior for the MacOS, except when a new window is a utility window. And I know what you're thinking, so please keep reading.



Its another pet peeve when a utility window has a title bar as big as the document window.


I'm not sure if you were in the Open Beta when I changed this, but there was a small revolt, as a result of the change to make the utility windows appear to be utility windows. Revolt would actually be a fairly docile term compared to a number of angry emails I received. So I changed it back. If there's a line forming of people who wish it were another way, I'm in that line. But for now, the user comes first.



also when a utility window falls behind the document window.


This should not be happening. If it is, it's a bug.



these are all problems due to Newtek writing its own window handling protocols. Bug-ridden, protocols that are simply unnecessary.

Weeeell, it's not that easy. The big issue here is that our existing users have certain expectations about how the product should work, and they've waited a long time for this UB. So for at least this first version, we're giving them what they asked for, even though it took more to do it now than it used to, because we've replaced all the old code this was hobbled together atop.



Newtek could cut a gigantic list of Mac bugs Out of LW, simply by removing the window protocols and letting Apple's default window classes do the work.

You're preaching to the choir. But for this first version of LW UB, we're releasing something that won't break our users' workflow, or change any of the major behaviors of critical things like windows.



But Not in carbon. You'd Have to use Cocoa. And I have heard all of the objections to this for easily 8 years, and none of them wash.

It's quite easy to do in Carbon. In fact, I think this was the *first* thing I did on the UB. And it's not in the final version, due entirely to user demand. The way it works now is not by accident. There was a ton of code already in place to work around the default Carbon OS behaviors to deliver what you're seeing in the product. I'd like to change it, but it certainly won't be on this first release.



And, throw your poorly designed and highly antiquated Text entry system into the woods, use apple's NSTextField (a class in cocoa, which can easily be programmatically generated) or a subClass thereof.

We already replaced the text system in the UB. It should work properly now.



no more will we be stuck with a poor man's windowing system, or text boxes that display nothing, text boxes that forget that they are in focus, or simply redirect your text input to another box.
The text redirection should not happen anymore. As for the windowing system, it is what it is because our users demanded it. IMHO, it is not optimal. But breaking our existing users' workflow to meet my demands for UI conformance is not on the table for this first UB release.

-Chilton

eblu
08-14-2007, 08:33 AM
hey chilton!
I thought we weren't allowed to talk about the UB in the regular mac forum? :P
let me take a minute to let you know where I'm coming from.

I am about 8 years in my crusade to get specific and positive changes wrapped into LW. I have heard every one of the bullet points from both sides of this issue, and I am by no means a zealot. I am trying to point you guys in the right direction. I know the balancing act you must be doing, and I appreciate where you are (on the wire, 100 feet up, sans net). Having said that... these are My pet peeves. no holds barred, no consideration for any other user. In that, i defer to the democracy of the mob, but I of course reserve the right to think for myself (or I think they used to say: "think different". ;) )

But, I do have two points I want to send home with a big hammer.

1. Carbon will go the way of the dodo. Count on it. Apple will never say it outright, and it might not get scraped out of the os like classic was (sort of like used chewing gum off the bottom of your shoe), but it will change fundamentally someday when you are least expecting it (newtek is ALWAYS least expecting it), and every bit of LW that relies on ancient and venerable parts of carbon, needlessly, will break. there are numerous and explicit examples of this, and for most of them I was an "i told you so" kind of user.
there are 2 ways to avoid this problem, carbon or no. First: reuse apple's code, apple may not know best, but if Apple has solved a problem, you can be certain that if you use their solution, it will stay compatible... as in text fields. Second: stay current. if you opt to do something yourself, use the Most cutting edge libraries available. this ensures that your work will stay valid longer.

2. Lightwave's text field situation is not fixed. I'm sorry, having been in the trenches for a very long time, and also making huge mistakes in programming, myself (zero divides anyone?), I can recognise what the text subsystem in Lightwave for what it is. its an aged and loosely related system of half solutions for the same underlying problem. each fix you guys make, unearths more and more kludges, more bugs caused by old assumptions, and screwy logic that should not have worked at all in the first place. its not a unified system, if it ever once was, and to fix it... you guys would Have to re-engineer it. so why Not let apple do the heavy lifting there? You'd cut down on code, you'd be able to port the logic that allows users to type in simple evaluations (like : 30+45), and Apple would Keep your text field up to date automatically.

Chilton
08-14-2007, 12:54 PM
But, I do have two points I want to send home with a big hammer.

1. Carbon will go the way of the dodo.


The reason most cross-platform apps aren't using Cocoa is that their existing drawing and event processing models don't match those used in Cocoa. LightWave is no exception. Carbon is closer to how that other platform does things.

That's not to say LW will never be a Cocoa app. It's just not going to be this first release of the UB.



2. Lightwave's text field situation is not fixed.
*File a bug report* <-- it should be fixed.


..so why Not let apple do the heavy lifting there? You'd cut down on code, you'd be able to port the logic that allows users to type in simple evaluations (like : 30+45), and Apple would Keep your text field up to date automatically.

FWIW, the text issues were never really issues with text handling itself. They're issues with keyboard events, menu events, and window events, not being handled right. And they should all be fixed in the UB now.

-Chilton

Scazzino
08-14-2007, 02:49 PM
... As for the windowing system, it is what it is because our users demanded it. IMHO, it is not optimal. But breaking our existing users' workflow to meet my demands for UI conformance is not on the table for this first UB release.
...


I appreciate both sides of the fence on the windowing issue. I was one of the howlers when they were changed to palettes and started disappearing on F9, F10 etc. and disappearing when other Apps were in the foreground etc.

I think putting them back the way they were was the correct call, for now anyway, IMHO. LightWave's GUI was never really designed to support such palette windows so just making them follow the Mac OS palette convention really broke the LightWave workflow. I am one of the most vocal Mac purists that I know of and I was one of those asking for the old LightWave behavior to be reinstated, for now anyway.

Until LightWave's GUI itself can be completely overhauled to manage such window palettes that will actually enhance the user workflow, I think it's best to keep them working the way they do now... ;)

Scazzino
08-14-2007, 02:58 PM
Before the windows are wholesale changed to palettes, each individual window and its purpose and use needs to be carefully considered. There are some windows that should remain visible, even when LW is in the background, or when expose is used, others would be OK to disappear. The overall use and workflow of the entire GUI itself needs to be carefully considered and most likely rearranged before changing some of the windows to palettes would actually be an overall benefit. I'm sure there's a place for Mac OS X's palette windows, but I didn't like it at all when most of the current windows were turned into palettes and started playing hide-and-seek with the user... I'd rather see too many windows than have vital information constantly disappearing on me... ;)

Scazzino
08-14-2007, 03:10 PM
I do have a few Mac LW pet peeves though...

I've always hated that LW's use of the command key and the control key are backwards for Mac OS X...

In Mac OS X the command key is used to make a discontinuous selection and the control key is used to invoke the right-click pop-up menu using the left mouse button or a one button mouse...

LW has always done this backwards...

This breaks my concentration every-time I switch back and forth from LW to the Finder etc... I always hit the wrong key for discontinuous selections and have to pause to get my bearings...

I'd also like to be able to assign real Mac command key shortcuts in the shortcut editor.

I'd also like to build my own real mac menubars like in modo. One thing that's nice in modo is that since we can build our own real Mac menubars we can override the shortcuts using the Mac OS X control panel to get real command key shortcuts.

Just some thoughts for future UB development... ;)

toby
08-15-2007, 02:01 AM
they were changed to palettes and started disappearing on F9, F10 etc. and disappearing when other Apps were in the foreground
That was awful, especially the Image Viewer disappearing. That, and the fact that you couldn't tell what window was in focus, or whether a hotkey was going to work or enter a characer in a field. Maybe there's a way to keep those things without hanging onto legacy code. Don't really see why it's worth it though, palettes just save a tiny sliver of window space and can't be minimized.

dfc
10-23-2007, 11:24 PM
Did I miss it, or has no one here mentioned the OBOD?? from version 5?
Orange Bar of Death. That was before we even had opengl.

And I don't know what you call it, but scrolling any keyframed graph editor left a mess on your display. I don't think they ever got that fixed up and till I quit buying LW upgrades at version 7.5. They just always seemed like they were another generation or 2 away from fixing stuff on the mac. I gave up years ago.

Chilton
10-24-2007, 06:12 AM
Hi,


I've been making requests for this sort of thing for just about 7 years now, once or so every few months, finally giving up on Newtek about a year or two ago.


Please keep in mind I started here a little over a year ago. However, I know this is something the guys that work on LightWave's core have been working on.



go get this:
http://www.amazon.com/Cocoa-Recipes-Mac-OS-X/dp/0201878011/ref=pd_bbs_sr_1/103-6789027-6840642?ie=UTF8&s=books&qid=1178629663&sr=8-1


What is this Cocoa thing everyone keeps talking about?

-Chilton

eblu
10-25-2007, 05:43 AM
The reason most cross-platform apps aren't using Cocoa is that their existing drawing and event processing models don't match those used in Cocoa.
-Chilton

great! cocoa is amenable to drawing and event processing model changes tho. from the perspective of someone who is putting in the time to learn the cocoa libs, it seems that all of the venerable and established app devs, are avoiding coca Not for any incompatibility, but simply because its new. check it out, it won't bite, and it might actually be fun!

Chilton
10-25-2007, 05:51 AM
Eblu,

Why do you assume I'm so new to Cocoa?

-Chilton

Mike_RB
10-25-2007, 09:55 AM
What is this Cocoa thing everyone keeps talking about?
-Chilton

Maybe because of that? :)

jwiede
10-25-2007, 11:08 AM
I believe that was Chilton being what Alanis Morrissette terms "ironic". 8~

eblu
10-25-2007, 11:55 AM
Eblu,

Why do you assume I'm so new to Cocoa?

-Chilton
its not that I assume you (or anybody) is new to cocoa, its just that I seem to be the only person who knows some of the finer, and immediately applicable points of the tasty chocolate flavored treat. All of the venerable entrenched app dev teams seem to look at it, and say "it doesn't do (insert thing here), the way we do it, so we can't use it" My assumption, is that devs are loathe (rightly so in most cases) to arbitrarily change things.

The Dev's assumption is that moving to cocoa IS arbitrary. At some point, Carbon will cease to exist, before that for a very long time Carbon will be effectively end of life'd. Then there will be a point in which Carbon will disappear and several products simply won't work. if you make the conversion before this happens, Newtek won't be caught with its pants down again. I tell you, the pace is picking up, and Apple is showing all of the signs that Carbon is end of Lifed, in bugfixOnly mode, and they are looking to jettison it, in just a few years.
moving LW to Cocoa is Not an arbitrary change. Its probably not easy, its probably a lot of work. That work will be: timely, more enjoyable, and easier, if the change is gradual, and started way before it becomes necessary. Alot of the ground work that must be done, is simply whipping the code into shape, and making each bit of code more "objective"... which can only benefit Newtek in a very general way.

And granted I don't know what is going on behind the closed doors or anything, I just have words that are written down in this forum to go by. and the words have been dismissive (from reps at newtek as a whole) of the value of moving more towards Cocoa. They have been specifically fuzzy on exactly what cocoa really offers, and if not completely wrong, then definitely
inaccurate on the details. Inaccurate in a way that makes all of the difference.

And hey, please don't feel singled out, I've taken Adobe to task for the very same issues. :) at the end of the day, I just want to see my money converted into R&D that is valuable to me... just like everybody else!

Chilton
10-25-2007, 12:12 PM
Hi,


At some point, Carbon will cease to exist, before that for a very long time Carbon will be effectively end of life'd.

Well, if it's any comfort, I think I said something very close to that on this forum a year ago.

My first work for NewTek, before working on LW, was writing the Mac version of their iVGA. It's a Cocoa app.

-Chilton

Chuck
10-25-2007, 01:10 PM
I just have words that are written down in this forum to go by. and the words have been dismissive (from reps at newtek as a whole) of the value of moving more towards Cocoa.

Clearly, you've been talking to the Sales folks again, and they thought you were discussing favorite hot beverages. ;)

eblu
12-09-2007, 11:03 AM
cute chuck. cute. are YOU a member of the sales team?

virtualcomposer
08-04-2008, 03:48 PM
One of my pet peeves is when I load layout, I have to reload all of my surface editor stuff. That's fine if I've only got a few objects but when I have to reload 50-100 little peaces, that becomes a pain. I think that loading your scene, obviously I want my objects to contain what I last had. Mabee having an option to "load all" from last save would be nice. The undos are a pain to. If I accendently delete an object, I have to reload and then load all of the layers again. I wish I could just undo and get the object back. One Undo button would be nice. Most people that use undo are undoing something withen a few steps from the present so having an undo button in different windows is a tad bit confusing.

toby
08-04-2008, 10:47 PM
... someone's not saving their objects before they close their scene! Anything you do to an objects' surface saves with the object, not the scene, so make sure you hit "save all objects" or "save object as".

toby
08-04-2008, 10:48 PM
Are you really a Film Orchestra Composer??

virtualcomposer
08-05-2008, 12:38 AM
Hey Toby. Yeah, I compose for film & television. Many times, animations or commercials. Yeah, it's just a pain to load them back up again. I always save my objects but it's a job to reload them when you have allot of them.

toby
08-08-2008, 09:39 PM
Hey Toby. Yeah, I compose for film & television. Many times, animations or commercials.
That's totally kewl
I'm surprised more people don't try to get into movies, it's a blast. What films/tv have you composed for that we may have heard of?

CAClark
08-09-2008, 04:28 AM
just found one thats been around since at least 7.5 and I had forgotten because I learned Not to use it! Texture guide. it crashes frequently! PC AND Mac!

I can't recall it ever crashing. I use it often.


Cheers!

eblu
08-15-2008, 11:10 PM
here's a venerable, and persistent bug.
Graph editor crashes.
they ain't fixed yet.

the way it works is that when the graph editor is left open, you run the risk of a crash.
Usually the crash occurs as you select a key, or try to scrub in the graph editor or the main window, while the graph editor is open.

it really feels like an openGL or a memory bug, but I've had 4-5 different rigs (machines, graphics cards, ram etc...), many different software combinations (os X 10.whatever... and LW ver 6.something to 9.3.1) nothing is the same through all of that, no common denominator, not even lightwave is the same. it doesn't make any sense, but there it was today, the same as it was when the graph editor was introduced. (5.6 didn't have the problem... I can't even remember WHAT 5.6 used in place of a graph editor. Boy, were those strange times)

toby
08-16-2008, 04:34 PM
Maybe I don't use it as much, but I've never had a chronic problem with the graph editor, even when trying to drag hundreds of keyframes which made it hang for several minutes.

Forgive me, I'm sure you've been through this before, but are you doing something else that reduces stability like using .jpg as textures or have the hub running, or is it that you work with big scenes? You seem to have less stability than I do overall, through all these os's and systems.

Meshbuilder
08-16-2008, 05:24 PM
I have one.

The Audio Channel Modifier in the Graph Editor on Mac.
Try to load any audio file and see what happens.

I know I wrote something about this on Newtek´s forum 2003 and it still doesn't work :)

Mr Rid
08-16-2008, 05:47 PM
The oldest bug I can think of is Cast, Receive, and Self shadow options can not be disabled individually with shadow maps. For some odd reason you have to disable 2 or more at once for any to work.

I guess fog will never work right with transparent objects.

World coordinate displacement has not worked for a few versions, but it works in Textured Displace (there are several weird things in Displacement and so always use Textured Displacement).

Distance Between Particle gradients have not worked in dissolve, color, luminosity, opacity channels since inception.

Envelopes dont work in some of the wind channels I dont recall exactly offhand.

Cant have negative start frames for image sequences since I think v7.5.

Undo is still just silly.

I dont get why I cant make a preview and minimize LW or have it in the background without corrupting, when I could do this in LW 5, and in Viper, or Fusion.

Also in LW 5.6 you had 'none, add, replace' alpha options for HV that disappeared with 6... and you could 'ctrl+ left-click' in the hyper texture sample window to see an immediate little animation of how fast the 'effect' speed is moving in 5.6... and you could zoom/limited region in the HV preview... and there was a simple 'clear motion' button in the motion editor... and you could have both linear and TBC on a keyframe... and there was a Rotate Path tool... and you could throw a displacement on baked particles (PStorm).

Surrealist.
08-17-2008, 10:58 AM
Don't know if this fits in or not. But how about numeric inputs for Translate Plus?

paul summers
08-17-2008, 01:13 PM
I have one.

The Audio Channel Modifier in the Graph Editor on Mac.
Try to load any audio file and see what happens.

I know I wrote something about this on Newtek´s forum 2003 and it still doesn't work :)

me too "lets hope they fix the audio" in 9.5"
after all this time............years

Chilton
08-17-2008, 07:27 PM
Hi guys,

Please explain this one. We've changed the audio section a lot in 9.5, so make sure this is fogged if it's really not already fixed.

(or at least give me more detail on what's wrong)

-Chilton

evolross
08-17-2008, 08:23 PM
Here's something I always get annoyed by...

When moving a keyframe in the dope track, I'm never able to move it to the very first frame (usually 0) or the very last frame.

For some reason it just doesn't want to go! It'll get close, but no cigar. Sometimes after several tries, it'll finally get there. :confused:

eblu
08-18-2008, 08:16 AM
nope.
no hub, no system mods, no textures at all on this scene (don't use jpegs in any case, LW has a bug there.) we're talking about a very simple 2 keyframe camera move, that I'm trying to tweak the bezier handles on. And like I said, this is a persistent problem across the last 8 years or so.
the graph editor is set to track selection, but thats really the only change made to it. teh menus are stock, the configs are stock, no 3rd party plugins at all.
the hardware is stock with one exception, I have a fibre card for connecting to our san, but THAT shouldn't be a problem, its got nothing to do with display.
I did identify a bad graphics card in my system, but that was swapped out months ago, and both the ram and the current Card (ATI Radeon X1900) test just fine.

toby, there are problems in LW that I don't run into anymore that new users run into all the time, after trying to figure out why, I realized that it was because I had learned just to avoid doing things, that should work but don't. Then I realized that this was BAD for lightwave because nobody actually reports the problems (or the veterans tell the new users they are doing it wrong)
Thats why I started this thread. so that we had a forum to talk about things that are problems that have somehow escaped the notice of the dev team, because we have subconsciously edited them out of our workflow, lessening the value of LW. Then somebody at newtek made the thread sticky. I think your stability is partly due to having learned what not to do. I'm a stubborn sob. if there is a feature on the box, I want to have the availability to use it, without gotchas and restrictions. So I use it, and if I run into a problem, I try to speak up. I've had problems that are operator error, but crashes by definition cannot ever be operator error.

Chilton
08-18-2008, 11:23 AM
Hi Eblu,

Please make sure you get a crash log in for that. I haven't seen that myself, and I keep the graph editor open quite often. A crash report in this case might lead us directly to the culprit.

-Chilton

Meshbuilder
08-18-2008, 01:40 PM
Hi guys,

Please explain this one. We've changed the audio section a lot in 9.5, so make sure this is fogged if it's really not already fixed.

(or at least give me more detail on what's wrong)

-Chilton

1. Create a null and open the Graph Editor.
2. Go to Modifiers and Add Modifier - Audio Channel.
3. Add any Audio File.
4. Close the Audio Channel Panel.
5. Now try to Zoom around in the Graph Editor. Or try to do anything at all.

Now try this in Windows and you will see how it should work.

Chilton, if you fix this bug you will be my hero this year! :)


Fogged:

https://secure.newtek.com/FogBugz/default.asp?15565_fsvm

toby
08-18-2008, 09:46 PM
nope.
no hub, no system mods, no textures at all on this scene (don't use jpegs in any case, LW has a bug there.) we're talking about a very simple 2 keyframe camera move, that I'm trying to tweak the bezier handles on. And like I said, this is a persistent problem across the last 8 years or so.
the graph editor is set to track selection, but thats really the only change made to it. teh menus are stock, the configs are stock, no 3rd party plugins at all.
the hardware is stock with one exception, I have a fibre card for connecting to our san, but THAT shouldn't be a problem, its got nothing to do with display.
I did identify a bad graphics card in my system, but that was swapped out months ago, and both the ram and the current Card (ATI Radeon X1900) test just fine.

toby, there are problems in LW that I don't run into anymore that new users run into all the time, after trying to figure out why, I realized that it was because I had learned just to avoid doing things, that should work but don't. Then I realized that this was BAD for lightwave because nobody actually reports the problems (or the veterans tell the new users they are doing it wrong)
Thats why I started this thread. so that we had a forum to talk about things that are problems that have somehow escaped the notice of the dev team, because we have subconsciously edited them out of our workflow, lessening the value of LW. Then somebody at newtek made the thread sticky. I think your stability is partly due to having learned what not to do. I'm a stubborn sob. if there is a feature on the box, I want to have the availability to use it, without gotchas and restrictions. So I use it, and if I run into a problem, I try to speak up. I've had problems that are operator error, but crashes by definition cannot ever be operator error.
Yes, I know you've been through a lot and you know what you're doing. I tried to avoid inferring otherwise, sorry if that didn't come across. ( I did forget you started this thread however ). But let me assure you I'm well aware of the concept of knowing what not to do for stability's sake, and am judging my stability accordingly. I do avoid the things I asked about, but those have little to do with graph editor crashes, which have been very rare for me. Just puzzled, forget I asked.

Mr Rid
08-27-2008, 03:50 PM
Here's one I've never understood and that no one else seems to notice. Why are incidence angle gradients backwards in LW?

According to logic and the LW manual, a parameter value of "0" is "the angle (in degrees) of the surface relative to the Camera," or more simply put, '0 is the surface facing camera.' '90' degrees should be the visible surface facing furthest from camera. But an incidence angle grad in any channel operates just the opposite where instead, '0' values apply to the surface facing away, '90' values apply to the surface facing toward.

A sphere and plane with the same color gradient in a side and top view- pink=0 should face camera, and green=90 should face away from camera.
62405
62406

Cageman
08-28-2008, 01:40 AM
Here's one I've never understood and that no one else seems to notice. Why are incidence angle gradients backwards in LW?

I've noticed it as well, but never got to actually ask anyone why things are the way they are.

lohic
08-28-2008, 11:51 AM
Hello, a bug noticed since the v8.5 version, noticed on this thread (february 2006) :
http://www.newtek.com/forums/showthread.php?t=45867

Shortcuts including the combinaison beetwin a num key and shift or(and) alt don't work on azerty keyboards (i'm on a mac).
It's quite annoying if you want to expand or contract selection with { or } you need to make alt+( or alt+) (on azerty keyboard ( = 5 and ) = °) :
http://www.newtek.com/forums/attachment.php?attachmentid=62455&stc=1&d=1219945745

I know it's possible to remap the key, but there's so many shortcuts including those key (and many off them for selection)

lohic
08-28-2008, 12:04 PM
noticed on this thread (february 2006) :
http://www.newtek.com/forums/showthread.php?t=45867


And I forgot this thread (march 2005):
http://www.newtek.com/forums/showthread.php?t=41613&page=4

Mr Rid
08-28-2008, 01:23 PM
I've noticed it as well, but never got to actually ask anyone why things are the way they are.

I just wonder how things like this slip so far under the radar. Then I guess its too late to change.

Chilton
08-29-2008, 07:52 AM
Shortcuts including the combination between a num key and shift or (and) alt don't work on AZERTY keyboards (I'm on a Mac).

That is most odd. I'll take a look.

-Chilton

lohic
08-29-2008, 08:02 AM
That is most odd. I'll take a look.

-Chilton

Thank you, that would be perfect to solve this bug, you'll make happy french, german and other strange language users !

Mr Rid
08-30-2008, 12:25 AM
Another thread reminded me that for as long as I can recall, Object Vertice emitters emit from normals the same as Object Normal emitters.

axebeak
08-30-2008, 11:45 AM
Why are incidence angle gradients backwards in LW?


I think those incidence angle parameters are not "angles" at all.
Instead it's something like dot(v, n) where v - vector from surface point to the camera, and n - normal vector.
Which is equal to cos(angle). cos(0) = 1, cos(90) = 0, hence the reversed order.

Parameter values entered in the gradient interface are scaled to be in 0..90 range, so I think actual value is cos(angle)*90.

For example, actual angle value for parameter 80 is not 10 (i.e. 90-80) degrees, but apparently something around 26 degrees.

JBT27
08-30-2008, 12:26 PM
Here's one I've never understood and that no one else seems to notice. Why are incidence angle gradients backwards in LW?

According to logic and the LW manual, a parameter value of "0" is "the angle (in degrees) of the surface relative to the Camera," or more simply put, '0 is the surface facing camera.' '90' degrees should be the visible surface facing furthest from camera. But an incidence angle grad in any channel operates just the opposite where instead, '0' values apply to the surface facing away, '90' values apply to the surface facing toward.

A sphere and plane with the same color gradient in a side and top view- pink=0 should face camera, and green=90 should face away from camera.
62405
62406


They are wrong - I noticed this when using Fprime which bizarrely seems to interpret them correctly. I flagged this up somewhere or other, Denis read and commented on my post, explained something about maths but confirmed it was reversed in LW, fogged it, and on one of the 9.5 OB releases I think you will find a comment from Chuck that incidence gradients now work correctly.

To my non-maths mind, I interpreted 0 degrees incidence as no incidence, and 90 degrees as right-angles to the line of sight

I haven't tried the 'fixed' one, but it clearly got fogged and apparently fixed.....

Julian.

radiancemedia
10-22-2008, 02:52 PM
For a lot of my scenes, especially those with modestly complex IK setups, after a certain point, every time I open the file and then open the graph editor, more and more copies of the graph editor pop open. On one file I am up to 6. I know of no way to stop this.

eblu
12-30-2008, 05:50 AM
radiancemedia,
its a general plugin thing. the graph editor is a plugin, sometimes LW gets confused and adds the plugin more than once, when you open the graph editor it invokes the plugin as many times as it is added to the scene... hence getting 6 windows.

I'm not in front of LW right now, but you need to find the general plugin window ( i may have my terminology a little off) , its usually in the utility area of layout, and you'll be able to see and remove this plugin. that "SHOULD" fix the problem.

it IS a bug tho, so I'd fill out a bug report.

correcting myself:
the place you find these plugins is the Master Plugin List, found under the utility tab.

landrafter
12-30-2010, 10:44 AM
There seems to be a bug with the Object Sequencer, in the object properties panel.
Just can't get it to work on the Mac. Really frustrating.:devil:
The rest of it rocks, though. :thumbsup:

Mr Rid
12-31-2010, 12:09 AM
There seems to be a bug with the Object Sequencer, in the object properties panel.
Just can't get it to work on the Mac. Really frustrating.:devil:


May try Object Sequencer 2 for Mac- http://www.dstorm.co.jp/dsproducts/lw9/FreePlugins/Layout/Object_Sequencer_2.html