In the rest of the (modern) world, a user normally indicates a typed-in number is ready by clicking outside the box, or hitting Enter.
TG (and I just discovered GeoControl as well) has real-time entry. If I have something like an auto-generate switch enabled, this causes fun things like something....being....re...built...every...time...I...type...another...digit. aaaaaargh!!!!!!!
Another fun example: select all the digits first then start typing. If the first digit would be an invalid entry, instant choke!
I've gotten used to using a Graycode approach (only one digit changed at a time) to mediate my number entering in TG, but today I reported a bug in GeoControl that I only discovered BECAUSE of the same number-entry problem. (and it took me quite a while to realize because once an invalid number was entered, it permanently broke the GC code until the exe was restarted)
That's when I got sick and typed up this lovely post.
Are we stuck with this? GC and TG both have similar looking (dated) interfaces and I wonder if this is due to similar graphical widget/window libraries? Delphi?
thanks
Well, in TG2's case it's just a UI quirk that needs fixing. I'll make sure it's in our bug DB and it'll get taken care of in a future release. I don't know about Geocontrol, but TG2 uses a custom UI library.
- Oshyan
Please don't change that. It is very useful for testing as a render is going.
GeoControl is developed using PowerBasic; it gives away this information because when there are errors, you are shown the filename and it ends with the ".pb" extension (and, if I remember well, this was also officially stated by Cajomi on his forum).
Hi Greg,
Quote from: gregsandor on May 15, 2010, 02:48:52 AM
Please don't change that. It is very useful for testing as a render is going.
You are really asking for trouble by changing values during rendering. Although TG2 lets you do it, it's not really very safe and could lead to crashes. It might be safe to do with some params, but in general you shouldn't do it.
Regards,
Jo
Hi,
First off, the realtime update behaviour is by design. Obviously there are some situations where it's inconvenient, and unless it's decided that a change to a lose focus/enter approach is decided upon then the bugs that need fixing are the situations where it causes problems, such as you describe. I personally think having to change focus or hit enter to have a value accepted is kind of retro, rather than modern.
Quote from: shadowphile on May 15, 2010, 01:57:34 AM
GC and TG both have similar looking (dated) interfaces and I wonder if this is due to similar graphical widget/window libraries? Delphi?
TG2 on Windows uses standard Windows controls. Where controls are custom drawn, mainly to get around poor behaviour in the standard controls, the controls are drawn using Windows theme functions to ensure they take on the standard OS appearance. So, basically, they look however the OS (or rather, your theme settings) wants them to look.
Regards,
Jo
Quote from: jo on May 15, 2010, 05:26:13 AM
Hi Greg,
Quote from: gregsandor on May 15, 2010, 02:48:52 AM
Please don't change that. It is very useful for testing as a render is going.
You are really asking for trouble by changing values during rendering. Although TG2 lets you do it, it's not really very safe and could lead to crashes. It might be safe to do with some params, but in general you shouldn't do it.
Regards,
Jo
I know, and it's worth the risk to me. I almost never crash TG (except for memory limits) and in the cases where I test this way so far none.
I don't see the relevance of whether a control response is retro or not. My keystrokes should not be interpreted as MY number until I say so. There are numerous fields tied dynamically to the internal models and needlessly cycling the cpu with meaningless numbers before I'm done typing...well...that's just not right. :'(
(which reminds me, the other day I was giving a password to a coworker and he ran off after I had only said the first syllable... ???)
Jo, this is a little off subject. The only time I find the input of a number inconvenient is using the carve river operator for heightfields. A 'GO' button would be wonderful in this instance.
Quote from: gregsandor on May 15, 2010, 02:48:52 AM
Please don't change that. It is very useful for testing as a render is going.
I don't think you understand. Say a setting is 23 and you want to edit it to 24. You first delete the '3' and the program starts re-rendering the preview based on a value of 2 which is what you are left with. Then you type the 4 to make it 24, restarting the render once again. Alternatively, you could first type the 4 making it 234 and the render starts over using the value of 234. You then delete the 3 to get the value you want which is 24. This starts the render again.
NO SOFTWARE SHOULD EVER WORK THAT WAY. Editing a number is a transaction. It is comitted or rolled back all-or-none. You should edit the whole value and the new value isn't accepted as a transaction until you type Enter. It is at this point that a pre-render should start over. But press Escape, and the number should return to its original value with "no harm done". If you have a pre-render in progress, it is not interrupted. I can't see any use whatsoever in values being continuously taken as the new value as you are typing it. A seeming exception to this is with searches when the software is implementing auto-complete. But even in that case, it isn't actually submitting a search to the search engine with every key stroke. It is only making suggestions for (guessing at) completing your query text. Excellence can never be achieved by emulating a preponderance of badly implemented software.
Thank you shadowphile for making thie very important observation.
Select the digit you want to replace on its own(highlight with the mouse, that is), then type. One refresh.
Not ideal for more than one digit but, I can see the benefits in both real-time edition and user dependant edition.
Grass clumps and erosion/river operators are the only real problem nodes for this, I think.
Everything else only refreshes the 3D preview/shader previews, which should, in my opinion, be paused between most keystrokes. Mine is paused more than it is rendering, anyway.
Quote from: dandelO on May 15, 2010, 11:09:20 AM
Select the digit you want to replace on its own(highlight with the mouse, that is), then type. One refresh.
Not ideal for more than one digit but, I can see the benefits in both real-time edition and user dependant edition.
This won't work going from 19 to 20 (like dandelO says). With 19 in the field, you could go into notepad and type 20, select it and then Ctrl-C. You then go into the field you want to change and select the 19, then press Ctrl-V. It will work as a transaction. But I think that if the TG2 staff found you were using notepad to work around the deficiencies of their software, they should feel like they haven't done the best job they could.
Quote from: jo on May 15, 2010, 05:47:00 AM
I personally think having to change focus or hit enter to have a value accepted is kind of retro, rather than modern.
What would you think about a banking web interface that would submit a check for every digit you typed into (or deleted from) the "amount" field even in the 25th century? Personally, I think changing focus shouldn't even cause accepting a value into a field. It should leave what you are doing completely "on hold". Coming back to it (giving focus back to it) should let you pick up exactly where you left off like nothing ever happened. I hate it when I am in the middle of something and a stupid window pops up unwanted. This causes the focus to change and, in badly designed software, it causes an entry to be completed that you didn't want. VERY BAD IDEA. A lot of modern technology is proof that things don't always get better. They often get worse. What it boils down to is that a lot of people get used to using badly implemented software and they get frustrated with well-designed software because they are not used to it. It is a shame when well-designed softare is intentionally retro-graded to please the masses. Disasters become more common place, but the ignorant masses don't ever seem to realize that they brought it on themselves (and everyone else).
It it really that big a deal? It takes only a few tenth of a second to type a number compared to the several min the preview can take to finish loading.
The only similar issue I have found is that with complex networks, if they have been loaded for a while, there is a tendancy for the cursor to become ever so slightly "stuck" in a number input box. Pressing "enter" or "tab" or "clicking in the next box" dose not release it imeadiatly, it can take maybe half a sec to a seccond. Annoying but not serious.
Richard
Quote...Not ideal for more than one digit...
I did state that, as well. ^^
Really, though, how slow is your 3D preview rendering if you choose not to pause it between key-strokes?
I don't see why you
wouldn't keep your previews paused, anyway. Like you say, what's the point in unwanted rendering and cpu usage?
Get into the habit of using the pause/unpause button,
really.
Consider it your new 'refresh preview' button, instead of a constantly running process.
Quote from: cyphyr on May 15, 2010, 11:37:50 AM
Is it really that big a deal?
Well, yes. Transaction processing is a very big deal. Generally, the same library routines are used throughout your software. The magnitude of the disaster that might happen if you enter a wrong number depends on which field you are editing (and even in what application you are using). Programmers who design the library routines often have no control over what fields the routines will be used for in the future. Sometimes they don't even know what applications in which they will be used. They should design for the worst case. If you blow up a space shuttle by typing in a wrong value, re-rendering the next mission can take a very long time. My point is that input routines should help you do your job more reliably, not create pitfalls to help you make mistakes.
Quotebadly designed software...badly designed software...badly designed software...
I find this quite rude. The small PS team must be loving your input. To be fair, most badly designed
users complain and blame their tools. Terragen is NOT sending cheques from your bank account, it is NOT sending important passwords to colleagues, it isn't even claiming to simulate other 'well designed software'.
It simply is the way that this specific application works, it updates scene values in real time, plain and simple. There are the couple of exceptions we've already covered(HF operators/grass clumps) but I'd suggest rethinking how YOU, as a user, approach the software.
Quote from: dandelO on May 15, 2010, 11:57:34 AM
I find this quite rude.
My intent is not to be rude. It is the way I have always felt about transaction processing input routines from long before I ever heard of Planetside. I shouldn't have to change my opinion on this subject for the sake of being polite. Besides, the technicalities of how you effect a new value into a field makes it a fundamentally different problem from the issue of whether you want to re-start an on-going render or not when that field value has been changed. Since pre-renders can take so long in TG, I have no problems with the way TG handles it. I even commend them for their great job. ;)
The spate of recent posts by relative newcomers to this software about how to "fix" Terragen so new users can find it more friendly have convinced me that that is the last thing it needs. It seems the lower the barrier to entry, the more of this I see, and the less inclined I am to want to see new users. The bad is driving out the good. More than a few of us have used TG for more than a decade, and to see every day in this forum fewer and fewer discussions about substance and more about style is disheartening. There are plenty of functional rendering tools yet to be written and this constant clamor for UI fixes and documentation and other user-friendly stuff is, I'm sure, somewhere on the list of things to do, but a low priority as far as I'm concerned. I am always happy to see new people around and have been something of an evangelist for TG since I first began using it in the early to mid- 90's. Post less, make more art.
Quote from: gregsandor on May 15, 2010, 12:19:25 PM
The spate of recent posts by relative newcomers to this software about...
gregsandor- How recently have you observed this? Certainly you are not only talking about me. I find this comment very interesting. It might reflect a rather sudden attraction of new users to TG. What are the causes? Should we take a poll? As for me, I probably never would have become very interested in TG if it weren't for the animation capabilities.
As I reflect on my past input to this forum, I am tempted to think of my Avatar as a needle puncturing a baloon. Please don't get angry with me for saying this. The idea just came to me and I just thought some of you might find some ironic humor in it.
priceless thread ! ;D
Quote...the bugs that need fixing are the situations where it causes problems...
Couldn't agree more with this line from Jo's post.
The auto-updating 'nodes' are the only areas that require attention here. Nodes that are very power intensive, like the heavy-duty heightfield operators and internal grass, especially when it has lots of geometry in the form of thousands upon thousands of blades.
The first thing I have to do, for instance, when using grass clumps is, delete a zero from both the number of blades and clump diameter. This reduces compute time considerably. I usually don't need a default, 10m patch of grass, with 10,000 blades, anyway. A 1m patch of 1000 blades makes much more sense to me, in general, for scene building.
Ultimately, I'd like not to have to do such optimizations before even begining to edit grass clumps or, unplugging HF operators from the scene before editing but, the one or two occaisions where it is necessary to perform workarounds is
far cleverer a problem to 'fix', than a complete UI overhaul of the way TG handles every single input. That's counter productive work, on a developmental level and a user level.
Terragen, or the people who make it available to we users,
never told anyone that it was trying to be like another application that might handle user-input differently. It works very well at the job it is designed to do, in its own strategy, which is to update everything in real time.
I find it the
most stable 3D application I own, with the most user friendly UI as well. Two/three years ago, the bugs were extremely counter productive, bad UI inputs would shut-down the entire program, deleting random items, likewise, multiple other bugs of an equally fatal manner. The small team have worked
hard and hard to iron-out these things and I've not, for a long long time, seen the dreaded 'Terragen 2 has stopped working' message. I can't say that for any other 3D app' I own.
I'll load a really complexed geometry tree model, for example, in Vue/Carrara/insert app', and if it doesn't kill the program, I'm waiting on the system to come back to life for a long, long time... Creation time.
Throw that same model at Terragen, however, and Terragen will eat it up, burp in your face and smile mockingly at you:
'Is THAT all you've got? C'mon!!! Ha! Don't make me laugh!' It works differently than other 'glossy' 3D packages out there, and it's best suited that way.
Popcorn, Franck? :D
yup thanks :D
damn, the pause button is great, dude ;)
Generally, I think the positive benefits should out-weigh the negatives. I personally don't see many benefits of real-time data entry in TG2.
As mentioned, the "Heightfield make river 01" is a good example of a negative. Try changing the cut angle from 45 to 60. You get a new generation/calculation when you try to delete or change the 4 or 5. Then a second one to change the other digit. If you uncheck "make river", you get a gen/calc. But even with the river disabled, you can't change the data without a gen/calc. So what's the advantage? A new gen/calc is done when you make the last change, and I surely don't want to see what a cut angle of 4 or 5 looks like in the preview -- I want to see what 60 looks like.
I know there is a thread on this, but new user's are going to encounter this because "make river" is an interesting function to play with. But this is the most extreme example of a non-beneficial real time data entry I can think of and it's easy to see what shadowphile meant.
Oh, and the "pause button" doesn't stop the gen/calc process -- just the preview render.
Changes should be enacted on focus loss (to another control of the same application, not to another application) or, better, after and explicit ENTER press. Even better, dialogs with OK/Cancel/Apply buttons.
Bye...
Pause Button guys...
I don't understand why you don't use the pause button if you don't like "real-time" changing values ???
Quote from: Seth on May 15, 2010, 02:14:43 PM
Pause Button guys...
I don't understand why you don't use the pause button if you don't like "real-time" changing values ???
Yes but even if pause is used, generate functions still will happen every single number typed. So you want to type 1764... Press 1 *generate popup* press 7 *generate popup* press 6 *generate popup* press 4 *generate popup*. Even if render is set to pause. That just cuts out rendering the change, doesn't prevent the pesky generate windows.
I love realtime updates except there ;)
mmmh i see
then disconect the node, change your value, reconnect the node.
it works for heightfield river uh ?
Quote from: neuspadrin on May 15, 2010, 02:20:11 PM
Yes but even if pause is used, generate functions still will happen every single number typed. So you want to type 1764... Press 1 *generate popup* press 7 *generate popup* press 6 *generate popup* press 4 *generate popup*. Even if render is set to pause. That just cuts out rendering the change, doesn't prevent the pesky generate windows.
I love realtime updates except there ;)
This is exactly the point that shadowphile created the thread for in the first place. This is all about how to effect a new value. It is not about whether a new pre-render (or even final render) should be re-started after the value has been changed. The edit field you see on the screen should be a temporary buffer that allows an edit to happen. The user should have the option of cancelling that edit or committing the new value. At that point, and only at that point, should the application recognize that the value has been changed, all-or-none. Thank you neuspadrin.
and what about disconnecting/reconnecting as i said before ?
Seth- Having to tear my scene apart just to make a single value change and then having to remember how to put it back together is a disturbing thought to me.
I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.
Quote from: Klas on May 15, 2010, 04:40:34 PM
I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.
That works for me too.
Quote from: gregsandor on May 15, 2010, 05:00:36 PM
Quote from: Klas on May 15, 2010, 04:40:34 PM
I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.
That works for me too.
For such a basic thing to do you have to use a workaround ?
The good and old users are so accustomed to the way TG2 is ; they sometimes can not see that it could-should be in another way !
It is not only you , Gregsandor. Here or in other software forums you can see most of the time the same arguments ...
I said earlier that I like the fact that the values update as I type. The cost of a workaround is worth the functionality to me. Beyond that I have a list of three dozen things that I'd rather Matt and Jo concern themselves with before considering changing this behavior.
Don't you people have art to make? Go render something! :)
Quote from: gregsandor on May 15, 2010, 07:03:53 PM
...
Don't you people have art to make? Go render something! :)
LOLZ ;D
agreed:)
Richard
Nice to see such an important issue getting energetic debate. ;D We will of course consider all input and do our best to implement the best solution. Right now I see it as a compromise between present behavior and that suggested by some. The important areas of focus are obviously the heavy calculations, especially the heightifeld operators.
A full "transaction"-based system would be extremely onerous in my opinion. Having a *dialog* to have to confirm every numerical input would quickly be quite frustrating. I do think that lose-focus or Enter should confirm, and Esc can cancel. But we have Undo for values you want to back out of, no need for some explicit confirmation or narrowing the ability to confirm to just a few approaches (e.g. Enter *only*).
Anyway, we'll make the best UI balance we can, as always. :)
- Oshyan
Oshyan- I agree with all you've said. It's just those pesky little un-invited popups that force a change of focus and cause an entry in the middle of typing that I don't like. I have to ask myself "Now what was I doing before that nasty little popup interrupted me?" Even yesterday, I had Lightwave rendering something and it interrupted me (in mid key stroke) right in the middle of a Terragen test and LW yanked focus away from TG just to let me know it finished. I don't know how LW reacted to my TG key strokes. I wish it weren't possible for a program to force a change of focus but I guess we are stuck with it.
As far as the transaction processing issue, I really am only talking about making a transaction at the single value level, not at the menu level. I can see how that could be a lot more involved than the simple thing I had in mind which is pretty much what you just described.
its nice to see that my point has been well debated and I don't want to contribute any more noise. thanks for all the vigorous feedback.
One thought I did want to make clear is my assumption that field entry was handled at a fairly low level by a subroutine, probably as part of the framework used to build the interface, and rather than recoding for each control one would only need to change the default behavior (if not hard-wired)
Another anecdote...
I build complex engineering interfaces for R&D software that is heavily GUI oriented and controls HW as well as other real-time tasks, for use by others. Despite my best efforts to train the users ("its basically a beta, please let me know if you don't like anything or have problems"), I find out later when confronted by a problem they will often just play with the controls until they get the desired response and never tell me about their workaround! (I usually find out because their attempts at workarounds will crash something and THEN they go looking for me.) They are more interested in moving forward, just like the veterans of TG, and I can understand that. It's very frustrating for me though (at work) and I still don't have a good answer.
Quote from: gregsandorI said earlier that I like the fact that the values update as I type.
(http://www.terralights.de/terralightsII/images/smiles/icon_top.gif)
Quote from: gregsandorThe cost of a workaround is worth the functionality to me.
(http://www.terralights.de/terralightsII/images/smiles/icon_top.gif)
Quote from: gregsandorBeyond that I have a list of three dozen things that I'd rather Matt and Jo concern themselves with before considering changing this behavior.
(http://www.terralights.de/terralightsII/images/smiles/icon_top.gif)
(I usually find out because their attempts at workarounds will crash something and THEN they go looking for me.)
Been there. :P ::)
Quote from: Klas on May 15, 2010, 04:40:34 PM
I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.
Reading your most recent posts makes me think that you (and maybe gregsandor) still don't realize that there is a difference between the two distinct issues here. I think we all want new values to have immediate effect when a new value is entered. If the pre-render is taking too much of your CPU time on a render that is certain to have to start over, by all means, Pause it with the supplied button. But single key strokes within numerical edit fields cannot be expected to reliably reflect the new value until the appropriate string of characters is properly composed. Pressing the 'Enter' key is merely a way to tell the software "Hey, I am ready with the new number. You can use it now." If this were built into the library edit routine(s) that is(are) used to effect new values, you wouldn't have to hunt for some innocuous dummy field in which to do the edit just to later cut and paste it from (and then be left with putting the dummy field back to its original value). There is no sense in having to do that. With the "automatic temporary buffer" approach, I think that you would actually get what you are wanting (i.e. immediate effect on the pre-render and node network) along with everyone else.
I think it is great that this thread is revealing user's work-arounds to this problem. I loved reading shadowphile's personal story that was shared on the subject. Thanks a bunch.
Ok, I pick PabloMack for my team ;D
I really agree with what PabloMack just wrote.
If I add a Heightfield (generate) and go to the pixel or meter size fields and click to the far left of the digits and by mistake enter an "a". The preview restarts, and the heightfield disappears. No error messages. You look at the xml and will find it's set to zero for that field.
Here's another example that causes a crash on my computer:
Load TG2 with the default scene and add a Heightfield (generate). Select the Heightfiled generate and enable "Auto generate". Now go to the "Feature steepness" slider and start moving it to the right. I get a crash. I suspect what's happening is the program is trying to recalculate the changing value from the slider. Wouldn't it be better for the program to only do the new calculation after a second or so of non-slider movement? The slider seems to work like individual key inputs, but the slider is much faster and the software can't keep up.
If you'd put a part of the effort that you're currently putting toward these suggestions for changing Terragen, into helping out in say, my retroreflective shaders thread, I'd be more inclined to be sympathetic toward your views on how this program, which does what it does better than any other software, could be improved. Until I see some jaw-dropping renders and associated tgd's, or some practical solutions to shader requests, all I see is a bunch of new guys whose job or hobby isn't terrain modeling and rendering, who are going to lobby for changes that, since they don't really know what they're doing, will wreck TG.
This is getting pathetic now. Really.
On page 1 Jo said that the areas that need fixing are the areas that are causing problems, e.g. HF operators, that everyone knows will keep recalculating at each input. I'm happy with that answer. Is nobody else?
A lot of pissing and moaning about how it isn't the same as my other applications isn't constructive. Likewise a war of words between old and new users, creating a great divide where none is needed. True, I was pissed off with the recent 'badly designed software' thing being thrown about but, c'mon. We've all got better things to do than bitch and pick teams, even in joke.
Whatever, I'm no longer interested in this, if I need help or, if I can help, I'll post on relevant things. This is teenaged pish. I'm here only to learn and share input on TG. Who's with me?(and not in a 'team' sense! :D)
Quote from: dandelO on May 16, 2010, 02:05:41 PM
I'm happy with that answer. Who's with me?
Great! Please bring your brainpower over to http://forums.planetside.co.uk/index.php?topic=9830.0
XD
I agree, enough has been said arguing what should be a very obvious point. It's in the developers hands now.