Hi,
Is there a "Rule of 3rds" or "Grid" overlay view in the 3D navigator window?
I find I need to plot points, so far I'm holding up a piece of transparency paper with a grid drawn on it :-)
Any tool that does that in TG?
Thnx
Ash
Press 3 on the keyboard.
That's great thank you,
Is there a way to change the divisions?
At the moment it only allows 3x3 equal divisions.
Matt
Just discovered this feature, and appreciate that it's here. You may wish to modify it, however, to maybe replace it with something subtler like a dashed line, or a less aggressive colour or both.
Its certainly a good feature. Would be cool to see future updates include row and column control.
Perhaps sub rows and columns could have a dashed line.
I use this to help me plot cameras for geometry export.
Cheers
I think if you really want a tool like that with greater configurability, you should probably look to a 3rd party utility that works more generally. Something like this:
http://www.phimatrix.com/
- Oshyan
Actually what I am trying to do needs to be done in TG.
So here's an example
- Have a terrain that I want to export as an obj.
- Create a camera, set it to orthographic and rotate it to point down at the planet.
- Set camera position to the middle of the terrain and make sure the ortho width is square and, of course, the camera altitude is high enough to encompass the whole terrain.
Simple enough, but the issue is the resolution of the mesh is not high enough.
The solution is to export smaller patches of terrain. Since TG doesn't do this automatically, its all wysiwyg I need to position a camera at every location to extract that patch of geo.
So thankfully I can animate a camera moving across the terrain and write out an obj sequence.
The next issue is how do i accurately plot/place the camera?
Well if I have a grid overlay that would at least guide me to see where the positions of the camera need to be then I can copy paste these x,z positions to my camera and key frame it per position.
So far the only option in TG is the rule of 3rd overlay. I usually need to export more than 9 patches to achieve the resolution needed. So a grid of equal rows and columns that could be adjusted would be ideal.
I have literally be holding up a grid printed on transparent plastic sheet to my monitor :P
Attached is an image of what I mean, top down screen grab of the default TG scene.
Cheers
Ash
Hmm. It sounds like your use-case is incredibly specific, and even more of the kind of thing that doesn't really justify a feature change in the main application. Fortunately, if I understand correctly, it should be fairly easy to solve your need. Just create an image file with the grid you want, then apply it to the terrain and set the size equal to the size of the *total area* you want to export. Then you should see the grid squares. To make them show up better in the preview you could make them solid colored boxes instead of grid lines (which, being thin, might not show up well with the preview level of detail).
You may even be able to do something natively with the Simple Shape Shader and a Shader Array. See attached for a simple example.
- Oshyan
Adding to what Oshyan said have you tried to use crop rendering?
I haven't.So i don't know if it works.
You could cover the entire area you want with the camera and then only crop render the parts without changing the camera position.
I had always the opposite problem as the files were very big i got from Terragen.
I could use a Shader array to plot the points, only thing is when I mouse over the actual points the co-ords default to the xyz of the shader and I need to mouse slightly next to the points to get the terrain/world co-ord.
Crop region render would work but trying to animate crop left, right, bottom, top is more frustrating than herding catz.
I think I'll stick with my transparent plastic grid for now.
Thnx for all the comments :)
Have you considered exporting .ter from a generate heightfield combination, with your terrain as the input. There's an app I use to convert .ter into a displaced square mesh within max, called groundwiz. Gives clean welded results. The resolution is set by how many pixels you dedicate to the heightfield square defined in TG, by how many verts you use to those pixels.
An added advantage, is you can post process errosion into the .ter to bring back into TG.
The mapping process can be split between as many heightfield nodes as you want.
Thnx Hetzen,
Sounds like we have a similar workflow. If I understand correctly you would need to generate a heightfield at 4096x4096 for approx 4mil poly. I need approx 20mil per 1km patch, actually its probly higher :-)
From my experience rendering out that resolution in pixels from TG takes a loooong time. Its actually faster to export obj at that resolution (poly count). With the added bonus that obj will capture undercuts as well.
I use heightfields and obj to move between apps and although TG and WM handle heightfields/dispalcement well the same can't be said for the apps the final will be rendered in. Its not consistent across the board so I go with raw geometry at high poly count to ensure I always get what I am expecting.
Back to the grid thingy, all I'm after is an automated way to export very large terrains. If you havn't already download a trial of World Machine and look at its tiled export features. Basically you set the extents of the world you want to export, then set per tile resolution. There is nothing in Terragen to aid in automated batch process, except what I have described above.
This may not be you preferred approach Ashley, the Obj export doesn't export undercuts if the camera is straight above either. There will be holes in the mesh where top down shadow would be. An HF will fill those gaps, not with an undercut though. But usually acceptable for camera projection on non hero parts.
You can also designate any resolution and size for the HF output too and once you set up a grid of HFs with overlap to blend you have the same type of tile output you get in WM. Admittedly it's not as easy to set up, but where it's superior to WM is the amount of ram required to process each square. WM will need to process some aspects of the whole heightfield to render a tile, so you will soon eat into a lot of ram outputting 8-16k tiles. TG will work on a tile at a time. Which you can process in WM one at a time.
Also, with this approach, you can optimise areas that will not have as much camera focus, so render out background formations at a lower rez.
I guess it's all about what the scene is, to work out the best possible route you'll need for the effect you're after. Rendering TG terrains in other apps will always fall short of how TG renders displacement due to how TG tessellates at render-time, thus cutting down on app poly count. Plus transferring texturing is limiting without camera projecting. I've found that I use exported terrain into other apps for shadow mattes and positional sense for camera and animation work, export the camera back into TG and render those plates. Although that depends again on what the scene is.
Quote from: Hetzen on October 02, 2015, 07:43:08 AM
... the Obj export doesn't export undercuts if the camera is straight above either. There will be holes in the mesh where top down shadow would be...
Not sure about that.
I tried it with a strange ground displacement and except some parts (probably mostly because of too much displacement) it came out without holes.And it has more then one possible problematic part even.
Edit: At the render time the camera was above the stucture. The preview you see below is to show the object as it is in Terragen.
Mmm, very interesting.
That's interesting Kadri. When I've exported obj's, the back of stuff is usually occluded. But then admittedly I've always rendered obj from ground camera positions not top down. I've always used HFs for larger vistas.
Even so, the process of optimising dense meshes takes time to weld and smooth, the result is usually quite un-weildly in 3d apps, as well as having problematic areas to deal with.
Yeah optimizing takes too long time. That's when i see the 32 GB RAM in full use mostly and want more.
Manually fixing the problematic parts isn't fun either.
I hope Matt makes an optimised version of the micro exporter. With texture support it would be so great :)
Even the small decrease that you get by not exporting the normals (wasn't aware at all...duh) that Matt mentioned lately made me happy.
Quote from: Kadri on October 02, 2015, 02:07:04 PM
I hope Matt makes an optimised version of the micro exporter. With texture support it would be so great :)
He's done most of the leg work. For camera projection you may have to get a bit savvy with generating normal 2d passes to blend a start and end point on a texture projection to get the blend right without smearing on larger camera moves. It really does come down to the scene. A 500 pixel micro export does a reasonable job with a higher resolution projection.
Quote from: Hetzen on October 02, 2015, 05:31:02 PM
He's done most of the leg work.
...
Sweet.
Quote from: Hetzen on October 02, 2015, 05:31:02 PM
... For camera projection you may have to get a bit savvy with generating normal 2d passes to blend a start and end point on a texture projection to get the blend right without smearing on larger camera moves. It really does come down to the scene. A 500 pixel micro export does a reasonable job with a higher resolution projection.
Thanks for the info :)
:P :D
I'd have to agree to completely disagree with you Hetzen on all counts, sorry if I misunderstand what you say but from what it sounds like, how I am interpreting what your saying, your info just doesn't ring true to my experience :)
Every obj I export represents the terrain 1 to 1, hence why the high rez output. What I see in TG is what I get as obj.
I never get the holes you speak of. Even on really vertical parts I still get polys, not sure what the "holes" issue is maybe upload a tgd.
Exporting Heightfields I reserve for moving to WM. As final output they don't give me as much detail as obj.
Try lowering your resolution to something like 128 x 128 pixels but up the quality to say 5 and move a top down camera to an altitude above your terrain. You'll get a high resolution mesh, which I have found is faster than baking HF when trying to match quality.
With Texturing, I re-project my renders. When you say blend or avoid smearing I assume you are referring to the projection stretching which is common when projecting from a static camera. This is solved by rendering out a sequence, re-project and paint masks. This will get you 90 to 95% of the way there then of course you need a bit of manual painting for the final look development. Basically consider your TG procedural shaders (RGB) more as masks rather than finsihed textures.
Not sure how other users "clean" geometry post TG, I know obj verts are un-welded which can take ages to weld in say maya.
So I use Zbrush, and retopo instad of fix, its really fast. I get all the detail and have the tools to generate a clean subdivided mesh as well as split the geo into managable sections depending on what app the final render will take place.
As far as optimizing scenes, once I have my clean mesh I then can decide at render time which sections receive more or less subdivision and disp quality. This has worked so far with Mantra, Vray, and Clarisse. All of which handle larger terrains differently.
One thing however that is really tricky to replicate in other renders is the outstanding quality of a TG render, and its atmosphere.
Sorry for the epic sized post, but I hope it clears things up.
That's alright Ashley. Thanks for spending the time to describe the workflow you're using. I was merely pointing out another way of getting TG terrain out into other apps and pointing out some of the pitfalls with obj export.
For example I needed a tank track plugin to interact with terrain produced in TG. Because the dirt road in TG had quite a lot of detail in the displacements, the exported mesh had to be welded together in 3D Max and there were a few gaps left where fake stones were used. This caused havoc with the plugin, causing the tank to fall through the ground. The solution was to export a Heightfield and use Groundwiz to create a quad mesh from the .ter which worked like a charm.
We have a similar approach to using WM. In the attached image we had to produce an animation and 7k print images for American Airlines livery launch. Like you, I was having difficulty getting the resolution in and out of TG and WM to generate erosion masks that held up. In the end I split the hero part of the scene into a 3x3 grid of heightfields, eroded each in WM then blended back in TG. It worked out that WM would run out of ram exporting 8k tiles if I tried to do it all in one go, hence tiling the scene in TG. Heightfields are slow to export admittedly as they only use one CPU thread to process. You can run multiple instances of TG to output in parallel.
I've had some thoughts on trying to blend projections onto obj meshes that use the normal pass to separate out different static camera positions, which would free up a re-render if the animation changes, but I've not delved too deeply into that process.
At then end of the day, it's horses for courses and always informative on how others approach things.
PoseRay has a very nice Weld command...very fast as well
I was merely pointing out another way of getting TG terrain out into other apps and pointing out some of the pitfalls with obj export.
That's cool, I overlook that not everyone uses Zbrush. Most of what you, and others, describe as pitfalls are avoided with the tools in Zbrush. Gotta have the right tools in production :-)
Erosion in WM tends to knock out the details from TG or for that matter heightfields in general. So I use a lower resolution and simply export higher out of WM. (The more tiles the less ram needed for export ;-).
Get use to handling the micro exporter, as it will help you with exporting geometry for re-projecting.
Its good to see more support for an automated / batch export process. Be it for obj or height field.
Seems to be the peeps in production that require this feature more than others.
Cheers
That is one hell of an image, Jon :)
Matt
Thanks Matt. There's a few improvements I'd want to throw at it these days. They were happy with it back then so that's what it is. :)
Ashley, looks like I'm going to have to master Zbrush now. :)
Zbrush is just neat. I have a keen interest in that software.
And looks like I'm going to have to learn Houdini now :-)