Object Spacing Bug?

[jaf]

Not really sure this should be called a bug since I suspect the program is just doing what it is being "told" to do.....


I've been working with a scene with a lot of large populations and every once in a while I miss-type and either enter a zero or blank in the Distribution|Object spacing in a,b field (either a or b.)  Then, when clicking "Populate Now" or starting a render, the program goes into an infinite object creation process -- one core at 100% and memory use continuously climbing, and no way (that I've found) to stop, except ending the task.


I'm thinking this is an area where an exception should be thrown to warn the user of an invalid entry and not process the population.  The default for this field is 10,10, and it's easy (for me), especially when changing several populations, to accidentally delete the "1" leaving the "0" (I tend to tab through these fields and use the del/backspace keys to get say a "1", which seems to be a common number for object spacing.


What makes this especially insidious is if you have many populations and make this mistake, save the scene, and then start a long render, you will come back to a machine that's out of memory.


Another thing I have been wondering about is if it would be possible to title the population creation message window with the name of the population being computed?  If you sit and watch (and know which populations a larger and more time consuming) you can guess, but a labeled message would seem (to me) to be useful.  In fact, I've long been a proponent of an optional text file that shows each population with the number of instances created (the names and numbers already exist, so it wouldn't seem to be a huge problem or something that would have a major impact on performance.)


Sorry for the long post.   

[cyphyr]

I don't have an answer to your issue but I can add that if you use the command line version of Terragen (Tgdcli.exe) populations are named as they populate (I think, sorry if I'm wrong)
Richard

[jaf]

Thanks Richard,


Yes, I had forgotten that tgdcli did that.  I couldn't find the cli options, but simply piping it to a text file works fine (4260 lines of text.)  In Windows, it would look like this:


"C:\Program Files\Planetside Software\Terragen 2 Deep Edition\tgdcli" E:\GRAPHICS\Terragen2\scenes\filename.tgd > c:\TGDCLI_TEST.txt


Wouldn't be too hard to parse the text file.... I need to get more efficient with Sublime, so that's a good macro or scripting project.


[edit] Is there a command line reference?  I tried to find it in the Wiki and searches in this forum show -hide and -p, but I'm thinking there must be something in print or a flag/switch that prints i out to the screen?  Maybe I'm not using the correct search criteria....

[Oshyan]

C:\Program Files\Planetside Software\Terragen 2 Deep Edition\Docs\win_command_line.txt

It would be nice if 0 values weren't allowed for object spacing, indeed. But... I can't help but want to just say, er, slow down a little and check your work. After all, render time is probably going to be the larger part of your time investment.

- Oshyan

[jaf]

Hi Oshyan

Well... yes, it would be nice if I didn't make mistakes.  It's only happened a couple times in the past few years and the only reason I caught it was I hit populate now and noticed a blinking cursor in the b spacing.  As mentioned, if I had saved and started a large population render I wouldn't have know until I checked the render several hours later.


It's hard to slow down.  My job is a 24/7 multiple building management and I am a caregiver to a 99 year old who is blind, hard of hearing, and has dementia.   The time playing on the computer is constantly interrupted.  Glad my word processor and email client don't look at spell checking that way.

[jo]

Hi jaf,


TG should behave well regardless of input. We'll look into making the populator deal with a 0 spacing input. Thanks for letting us know about it, sometimes things like this slip past us.


I'll also look into making the progress dialog display the name of the populator.


Regards,


Jo

[jaf]

Thanks Jo!

[Oshyan]

Sorry if my reply seemed dismissive Jaf. As Jo said, we'll definitely take the feedback on board, and that would be true regardless. There's no doubt that it's something the software should handle better. I just find that doing anything in haste usually comes around to my disadvantage sooner or later, especially when it is a matter of a few seconds saved here or there, compared against minutes or hours for normal render times. Again, I don't mean to diminish the legitimacy of your problem report. Just a more personal perspective, I guess.

- Oshyan

[jaf]

Hi Oshyan,


No problem -- I'm a lot harder on myself when I make silly mistakes, and as I get older, I seem to be making more than ever.  So don't get old! 


In my former career I worked as a software engineer on military aircraft simulators and we had to make as sure as possible the operator couldn't make mistakes, like launching a missile inadvertently.  I guess a little of that mentality has held over in my hobbies.


I think I remember reading "we want to have Terragen remain lean and mean" or something like that.  I would generally agree, but some areas deserve some error handling, especially where some simple checks to inputs can be made (I'm not referring to very small inputs into fields like displacement  can result in errors -- just leaving a field blank or zero.)

[jo]

Hi jaf,


It's not so much a case of "lean and mean" but rather we typically don't have constraints on inputs to allow for maximum flexibility. In some respects this leads to a "give 'em enough rope" situation where entering certain values can make things really slow. However the situation you describe doesn't really come under this philosophy and is something where some input validation needs to happen or the behaviour for a spacing of 0 needs to be changed.


Regards,


Jo