(vent opens..)
I've got a lot of b-box objects, cameras, etc in my scene now. I'm finding it frustrating that I can't find any way to identify which is which. My 'method' right now is to guess, bring up the panel, then use the move arrows to move the object with the mouse and hope the position data changes. If not, I have to cntrl-z and try again. Most programs will at least allow one to select an object and see it selected elsewhere.
Not just a sigh, but a serious gasp of frustration! How did this program ever evolve with such massive holes in the user interface? Managing cameras is also a mess. The procedural tools are very powerful, but it feels like the whole GUI is a kludge with little forethought. I spend so much time doing experimental runs examining the effect of this or that parameter that I tend to lose focus on my objectives. It's true (my opinion that is). One of the things I do a lot at work is design man-machine interfaces. ('GUI' to the lay person)
Sorry, but between that and the unpredictably HUGE render times, I'm finding that I'm making very little progress when I could be whacking away at Blender and feeling productive. I don't have the resources to become a TG guru at the expense of everything else I need to finish my production.
My vote is that shaders and other terrain developments should be halted until the user interface can be brought up to a par with the basics we all expect from other programs.
(vent clangs shut)
Hi,
Ways to know and/or select an object:
- Mouse over the centre cross/origin for an object and a tooltip pops up telling you the object name and type.
- Context click on the 3D Preview and choose the object from the "Select object or shader" submenu.
- When an object is selected press alt-enter/opt-return to open its param view.
- It's possible to centre the camera on an object using either the Reset view camera button ( bottom of 3D Preview, 3rd from left ) and the "Centre on object or shader" submenu, or to use the same submenu from the 3D Preview context menu.
It's true we don't have anything that selects an object in the 3D Preview when it's selected in the project view list.
Managing cameras will be streamlined further in the future.
We're continually making changes to improve the UI, take a look at the change log for the latest version.
Regards,
Jo
thank you Jo for your patience amongst all the billowing steam from my vent. ;)
Amongst all four options, three still depend on one knowing what they are looking for, as opposed to helping identify something. (your methods however are better than my jiggle-it-and-see-which-one-changes method)
I'm still having problems with the tool-tips disappearing so fast I forget they are actually there, hence part of my frustration. They would be an immense help with regards to my complaints and I'll make another try at fixing it.
In the population and single object entries of the objects tab, there is a check box at the left top. This enables the pop/object when checked. If it is not checked, the bounding box disappears. Unchecking the show Bbox will cause the object preview Bboxes to disappear.
This way you can know which population/object you are moving around without the confusion.
Quote from: shadowphile on January 18, 2010, 08:26:25 PM
Sorry, but between that and the unpredictably HUGE render times, I'm finding that I'm making very little progress when I could be whacking away ...
I would like to help you address this particular complaint.
If you can submit a tgd that's taking forever for you to render, I will have a look and change parameters to optimize your render time, without loosing visible quality, and post it back here.
There are so many settings that you could just easily exaggerate, that it doesn't make sense to write about them here without a practical example. Sometimes, you can double render times with just one misunderstood setting.
There's a sticky thread about optimizing render settings here as well, definitly worth a read - just in case you haven't read it yet.
Cheers,
Frank
PS: by the way, which cpu do you use?
Quote from: shadowphile on January 18, 2010, 08:26:25 PM
Most programs will at least allow one to select an object and see it selected elsewhere.
This seems to be the standard way of doing it in other 3d apps. It would certainly be a lot more intuitive than relying on toolips and context keys to figure out which object your working with. So i'm with you on this one. It's these sort of things that can intimidate new users coming into the software and are just getting lost in it. Even for experienced users this would be a benefit.
I don't agree on the "HUGE" rendering times though. Are you sure your not maxing out some unnecessary setting? If you really are struggling with the rendering times and you have a decent cpu then I would take up Frank's generous offer, i'm sure your time could be cut down.
I know it is really long sometimes . But if you compare the render times with Blender , Lightwave ,Maya and such it isn't fair.
The way and what TG2 handles is different . Matt knows it better ,
maybe there can be more optimizations to make but don't expect the render times from other 3D programs such above.
If you would try to make the same things in the other 3d programs they wouldn't render at all most of the time .
Cheers.
Kadri
I would dare a guess that given the same level of detail calculations and the same hardware, TG2 will be faster in many cases than other comparable apps.
I'd like to see Blender, Lightwave et all handle anyware near the amount of vertices that TG's displacement creates, yet a lone render it. And still only be 6.5mb in program size, and just a few hundred kb in scene size (depending on how much paint shader you've used).
I understand your frustrations at getting to grips with what seems like an impossible program, but actually it's extremely open ended and very powerfull once you get a grasp of it, which does hold a strong place in a landscape orientated production line. What I would though do is question how much I expect of it to in that workflow, and more importantly, where are the short cuts. A big example being a plate background, enhanced in photoshop with actual photographs.
All this being said, it would indeed be good to have objects selected in one place show as selected elsewhere in the UI. ;D Improvements in working with objects are certainly worthwhile and planned for the future. Objects are not the strength of Terragen's legacy (see Terragen Classic), but we realize we need to embrace their use.
- Oshyan
A small and slightly off-topic remark is that I would really appreciate it to be able to disable the boundary-box of the heightfieldshader.
I often find it very annoying in my 3D preview, not only visually, but also when trying to select boundary boxes of the water for example, the mouse often "snaps" to the heightfieldshader. This happens especially when the boundary boxes are closely placed to each other or when the boundary box lines almost intersect in the preview. It's almost impossible to precisely select the boundary box of choice.
Many many times the boundary box of the heightfield is giving me these troubles, so being able to disabe that would be nice.
I second Martin's request. The boundary is only useful when determining the population size. It often gets in the way when I mouse over the preview to get slope or height information.
... or at least be able to "lock" the position of objects. Maybe a "lock all" and then the option to
unlock a specific object. Just a thought.
Just came back and found many more replies, very good ones. Let me reply to a few:
Njeneb: good idea, toggling enable to blink a bounding box.
my comment about selecting objects was a little ambiguous: by 'objects' I actually mean anything represented in the 3d preview, which tends to mean cameras and anything else that throws a representation in the 3D preview. Most of my shaders and heightfields have b-box enabled.
hetzen, frankB, Kadri: re: Huge render times.
I've read the stickies and others about minimizing render times. I did my own study on using both crops and whole pics while adjusting just detail. 0.3 is good for decent previews, final renders can be evaluated at 0.6, only slight polishing added above that.
My biggest headache is that there are SO many parameters, and the effects are not additive in terms of either render time OR quality.
I'm not complaining about the render times except that they are normal result of the micropoly rendering technique and massive detail of the procedure textures. Compared to other programs TG is very powerful. If find that trying to explore variations on a displacement though can be very slow because the results are so tangled by so many variables that can't really be anticipated ahead of time, it requires a lot of trial and error. When I use cropping, I end up with a keyhole on my detail but not a very good overview.
Some of the things I would still complain about though are the previews. Sometimes the 3D preview itself is so slow that I render it instead, with considerably faster results. I tend to keep all the layers (atmos, lighting, shaders) turned off in 3D or it bogs down.
2D previews themselves can also be very slow, If I bring up a floating window and pull it out. It seems like the 2D previews are basically the same rendering technique as the 3D preview, just from an overhead camera. I've got a quad-core PC, I would think that a 2D preview window, even expanded, should be able to create a relevant image almost in real time. What the heck is sucking up so much cpu time? Perhaps a different kind of renderer for those images. (scalar field previews are pretty fast. It's the displacement previews that can take 30 seconds or more.) That makes it very difficult to do relative studies. My eye can't remember the image well enough from render to render to detect the kinds of subtle changes that are an important part of the evaluation process.
All in all, I think I just still need to work out my process flow. Lack of tooltips has been a real pain. Also, as my model grows in complexity, my node tree is getting very complicated. I'm using node functions quite a bit because they make more sense to me.
I've rejected the standard terrain/shader groups and started creating my own groups like 'world terrain', than saving it as a clip with the clip name AS the group container name. Although rather manual, this allows me to modularize my node tree, stabilize the values of my nodes, and work on just each node as needed when they need tweaking (by opeing in a new TG project.) A future macro system for nodes, clips, etc would be an immense productivity boost. I would LOVE to be able to enable/disable an entire group. Being able to link to an outside clip/group/macro (no proxy, just read only) would also allow a much more modular approach. For a program of this complexity and detail, being able to cleanly isolate, tweak, evaluate, then unisolate makes a lot of sense. Currently I end up turning a lot of stuff off or tweak the values down when attemping a study, and then I have to remember all the 'temporary' settings I made. Usually I forget something and chaos ensues, much later.
BTW, my life might be complicated by my rather lofty ambitions. TG seems to be mostly targeted at rendering one or a few stills, whereas I'm more attemping to build an entire sandbox world. That means almost any perspective from closeup to eagle eye are fair game. I wish I could set the 3D preview to a certain resolution and boundary and have it render everything. I could then fly around and check different perspectives. TG09 did this, what happened to TG2?
My product is a point and click game. Most of those are indoor-oriented, or have very limited horizons. I love the idea of a P&C game with large vistas and terrain as the setting.
My TG2 final outputs are high-rez cube faces. I'm trying for a sandbox approach with respect to the general terrain so that once I'm satisfied, I can just move the camera to plot-relevant locations and render another cube. I can't really just optimize for one camera angle like most stills. Originally I was just using TG to make skymaps for my cubefaces rendered in Blender. That plan entirely broke when I started getting involved in TG and now I find myself basically needing to use TG instead of Blender for my final renders. Still haven't worked that out, sigh. Yeah, I make my life complicated! :D
I tend to work with the simple shaders, especially when I am getting clouds and populations set up. When I am happy with those, I work on detail for the shaders. If a population is going to cover most of the ground/landscape, I let the objects be the quality. It seems to work well on my slow computer.
Quote...I would LOVE to be able to enable/disable an entire group...
There's at least one thing you can get instantly. Just make sure the grouped nodes you want to disable/enable together are captured inside the group node(or linked to it via capture if they're not inside the group box for any reason). The just hit key 'D'(default keyboard shortcut) to disable/enable the entire contents at once.
Edit: Also, holding shift and mouse clicking or, marquee dragging will let you select multiple nodes to one-move disable, aswell.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
...
Some of the things I would still complain about though are the previews. Sometimes the 3D preview itself is so slow that I render it instead, with considerably faster results.
...
I do this too. It is said that it will be multithreaded in the future . I am waiting for this too Shadowphile :)
Cheers.
Kadri
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
my comment about selecting objects was a little ambiguous: by 'objects' I actually mean anything represented in the 3d preview, which tends to mean cameras and anything else that throws a representation in the 3D preview. Most of my shaders and heightfields have b-box enabled.
Yes, of course this makes sense. The camera would probably be considered an "object" in this context.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
hetzen, frankB, Kadri: re: Huge render times.
I've read the stickies and others about minimizing render times. I did my own study on using both crops and whole pics while adjusting just detail. 0.3 is good for decent previews, final renders can be evaluated at 0.6, only slight polishing added above that.
So what do you consider to be long render times?
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
Sometimes the 3D preview itself is so slow that I render it instead, with considerably faster results. I tend to keep all the layers (atmos, lighting, shaders) turned off in 3D or it bogs down.
This is mostly because the 3D Preview is not yet multithreaded and the main renderer is. So if you're on a multi-core system, it will certainly be faster to just render a quick, low detail preview. We are working on multithreading the preview.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
2D previews themselves can also be very slow, If I bring up a floating window and pull it out. It seems like the 2D previews are basically the same rendering technique as the 3D preview, just from an overhead camera. I've got a quad-core PC, I would think that a 2D preview window, even expanded, should be able to create a relevant image almost in real time. What the heck is sucking up so much cpu time? Perhaps a different kind of renderer for those images. (scalar field previews are pretty fast. It's the displacement previews that can take 30 seconds or more.) That makes it very difficult to do relative studies.
It's basically the same rendering system, though simplified (e.g. no atmosphere). Once the main 3D Preview gets multithreaded, I imagine this will too. I don't know if it's really as easy as you imagine to speed it up with a different rendering method either. From what I understand the rasterizing the internal functions is the CPU-intensive bit, and the "rendering" process per-se takes a lesser proportion of the time.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
My eye can't remember the image well enough from render to render to detect the kinds of subtle changes that are an important part of the evaluation process.
We have plans for some kind of "flipbook" functionality in the renderer in the future which should help with this.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
BTW, my life might be complicated by my rather lofty ambitions. TG seems to be mostly targeted at rendering one or a few stills, whereas I'm more attemping to build an entire sandbox world. That means almost any perspective from closeup to eagle eye are fair game.
Actually the procedural approach to world building is really considered the primary method, which is inherently global, essentially. So we're definitely aiming for tools that enable this way of working. Take a look at Nvseal's work or Efflux; both have done fantastic work in developing complete planets with great diversity, from realistic to fantastic.
Quote from: shadowphile on January 21, 2010, 02:13:07 PM
I wish I could set the 3D preview to a certain resolution and boundary and have it render everything. I could then fly around and check different perspectives. TG09 did this, what happened to TG2?
TG 0.9's preview worked completely differently and had a much easier task to deal with. Essentially all it did is what game engines do, it didn't have to "render everything" (as TG2 *would* have to), it just took static scene elements (heightfield converted to simple geometry, water plane), and then rendered them with OpenGL. The geometry was trivial to generate as no procedurals were involved, the textures were mostly faked (aside the sky, which you could see from the cloud generator window can be created fairly fast), and the level of resulting geometry was low enough to render quite quickly with OpenGL.
A method of caching generated procedurals in the 3D Preview for TG2 *is* something we're considering, but it's certainly not as simple as "Do it like TG 0.9". Virtually none of what was done in TG 0.9 likely applies to the bottlenecks in TG2's preview. But we certainly recognize those limitations and want to address them.
- Oshyan
kadri: u da man! ('D' toggling grouped nodes)
oshyan:
I tried to render a basic power shader with strata added, nothing else. Wanted an overnight beauty so I set detail to .6 and rez to 1600x800 and went to bed. 9 hours later I killed it...
I know, you want the file :) I'll see what I can do. My todo queue is buckling badly right now...
Flipbooking renders would be nice. I currently save multiple renders and toggle between them with Irfanview. (great for cropped renders because it has that nice 'autocrop' command that just removes all the black outside the image.
But it still doesn't change the fact that: I spend hours modeling in realtime in Blender, then hit render. Even if it's a big render, I still got a lot of feedback during the modeling process. TG however has virtually NO realtime modeling capability. The modeling is basically tweaking a hundred parameters and seeing what the change is. Every change requires a rerender, and the parameters are often so interactive that its very difficult to tweak-and-see, which is difficult in a freeform environment like TG.
In fact, the entire fractal procedural process is mighty slow, at least for the world-building we are doing. I imagine (with justification) the procedural algorithms plowing along with standard calculations. Are there any plans or ideas for massively streamlining the process using fancy algorithms? (the invention of the FFT comes to mind, making modern realtime spectral analysis achievable)
Glad to hear that my sandbox approach isn't wack. Counter to the usual advice with GG work: only build what the viewer can see, or is good enough.
Quote from: shadowphile on January 25, 2010, 03:45:20 AM
kadri: u da man! ('D' toggling grouped nodes)
...
It was , DandelO ;)
Kadri.
oops, soory dandelO, YOU da man!. Kadri, would you please hand him the 'da Man' sceptre.
(the good side is now anarchists trying to stick it to 'the Man' will now puncture HIS styrofoam noodle cups.)
Ok.
Kadri, I'll split it with you. ;) We half da man each, now! :D
What are you talking about? LOL :)
Kadri.
Certainly we want to do as much as possible to improve the process of building things procedurally. You're correct that constant re-rendering is non-ideal but necessary at this point to really get an idea of what your changes are doing. A multi-threaded preview should help with this in the future, along with better (and faster) shader and material previews, e.g. being able to apply a material to a sphere, to move the shader's perspective, etc.
- Oshyan