number entry in TG, why is it 'real-time'?

Started by shadowphile, May 15, 2010, 01:57:34 AM

Previous topic - Next topic

PabloMack

#15
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.  

dandelO

#16
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.

PabloMack

#17
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.  ;)

gregsandor

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.

PabloMack

#19
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.  

Seth


dandelO

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.

dandelO


Seth

yup thanks :D
damn, the pause button is great, dude ;)

jaf

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.
(04Dec20) Ryzen 1800x, 970 EVO 1TB M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 457.51 (04Dec20), Win 10 Pro x64, Terragen Pro 4.5.43 Frontier, BenchMark 0:10:02

latego

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...

Seth

Pause Button guys...
I don't understand why you don't use the pause button if you don't like "real-time" changing values ???

neuspadrin

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 ;)

Seth

#28
mmmh i see
then disconect the node, change your value, reconnect the node.
it works for heightfield river uh ?

PabloMack

#29
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.