I was discussing the use of an exported TG 'heightfield' in Speedtree (for growing plant pops on, to be used as one object in TG again) with Doug (Zaxxon). It would be great if plants could grow from cracks around rock outcrops, searching for light, and not have a predestined (simple) angle for the whole plant.
So I did a little experimentation.
But exporting a portion of terrain with overhangs is not possible to my knowledge (or is it?). So I thought, why not export a vdisp map, to be used in a sculpting app like ZBrush. But I can't get it to work, and it may not be possible.
So I derived colors from the rock+overhang through a displacement to vector (blue node) and a vector to color. You get the three colors alright, and I simply (for proof of concept) used the previews to printscreen the greytone images, copied them to the RGB channels in a TIFF, and set it to 32-bit. Perhaps a rather primitive line of thought, as it didn't work as expected.
Any ideas, guys?
When I tried this I found free scripts for maya that make it super fast and easy to create heightmaps of any geometry. I was first looking for ways to make vectors in the same way. But I have not worked on that project in a while.
My point is that it is a least possible to make vectors of objects for the kind of purpose that you are thinking. But even making the heightmaps was really hard without the script I found, even though it is really just a complex ramp. So finding a script would be ideal.
Of course if TG would export vectors directly, then so many problems would be solved.
As it is now, you should sculpt your terrain and have TG as the last step rather than the first. If you want to do anything like you are talking about.
Its not fun doing complex workflows with TG. Tg lacks too many tools.
Now if you have Z-brush, I can give you the instructions that Chris gave me based on his workflow for Snow White. But thats not easy either, and impossible without Z. But would do what you want it to.
Thanks, Michael. But I know how to extract a vdisp map in other apps like mudbox, but the point is to take it off TG. Though it would probably be easier to make the sculpt in another app, make the veggies in ST on that imported sculpt, export the veggies and the vdisp map and set up all in TG. In that respect you are certainly right. But I was just wondering if it could be done with some ingenious line of nodes from TG....
As far as I can remember it should be possible to export an .obj mesh of terrain.
Isn't it possible to use the micro-exporter for this? Seems to be plenty of info on the process, but I didn't see if that handles over-hangs. Certainly any mesh into ST shouldn't be too dense, but that could be 'decimated' from the TG export first. My thinking is to use the exported reduced poly terrain sample mesh in ST as a 'template' to create multiple populations on, which then would exported, and placed back onto the actual terrain in TG. Any thoughts on this approach?
QuoteBut I know how to extract a vdisp map in other apps like mudbox
Yes, I know. But you are not reading between the lines. This can be done by going to Maya first than to zbrush, you cannot do it with mudbox. What you are trying to do is how chris used TG in the film snow white and the huntsman. I know because he gave me step by step instructions.
QuoteIsn't it possible to use the micro-exporter for this?
Yes, but that is not enough, then you have to make a vector of the object. And this is where it gets really complex. Either you have Z brush, and get the object from Maya to Z following a specific flow, or you must somehow make the vector of the object in maya, which as of yet, I cannot find away to do. The best I could find was a heightmap of the object in maya when searching how to make a vector of a object.
The only PROVEN way to make a vector of a TG object is a maya to Z workflow. That workflow does not work with Mud.
On the other hand, If the idea is more simple here, than you could just paint maps on the TG object in maya (or most any program) if the map is only meant to be a population map, since TG objects do include overhangs.
Dune,
TO be clear, I was telling you that you cannot make a TG object vect with mud. You have to Have Z. Than you can, including overhangs from the .OBJ out of TG. But, if all you want to do is paint pop maps onto the TG .obj, than export the object to mud and paint the pop maps there.
The vectors' RGB representations are likely to have negative values which the shader preview can't display. And then there are issues with gamma correction and so on. So the screen grab won't work. But if you render an image of these vectors from an overhead camera, save the EXR, it might work. Use an orthographic camera, choose an ortho width, and use the same size of plane in the app you're exporting to.
Matt
Thanks, guys. The idea is to use TG as a principal source of the mesh, after you have made a complete, complicated terrain and want to use a close-up portion for exact veggie contortion, so to speak. The only problem then would be to locate the population (as one object) spot on. I'll experiment a little more with your input, Matt.
QuoteThe idea is to use TG as a principal source of the mesh,
Yes. The fact is that TG would be SOOOOO useful to so many more people if it could do what you want on its own. I have been learning other soft workflows for a while now, even unity and UDK now. I see people making things that are really easy in TG as it is, but they have to do a lot more work with the soft they use; more soft more steps.
If TG could output in more and better ways, it would really be a great thing!
I know, I know, I never shut up about this. But what can I say, its like cubic noise... The power is clearly there, but man, what a pain!
Love hurts I guess ;D
Quote from: TheBadger on April 21, 2015, 06:41:46 PM
QuoteThe idea is to use TG as a principal source of the mesh,
Yes. The fact is that TG would be SOOOOO useful to so many more people if it could do what you want on its own. I have been learning other soft workflows for a while now, even unity and UDK now. I see people making things that are really easy in TG as it is, but they have to do a lot more work with the soft they use; more soft more steps.
If TG could output in more and better ways, it would really be a great thing!
What would be the ideal format/method for getting terrain into Unity and Unreal in your opinion?
Matt
Add vector maps.
See my million other posts on why that would be awesome. ;D
And make it so that a single map render node can be added anywhere in the chain, and that everything above it, regardless of how it was created, gets rendered to the map.
To me it is most important that everything gets rendered regardless of how it was made in TG or what order they are in in TG; imagemask, DEM, PF so on.
So anything above the new map node is rendered out to the map.
I do not find that to be the case in TG now.
TG should produce all of the maps that are made and used by other soft. It should also read them. That is those maps that are regarded as standard, + Vector.
IMO.
Hello there, Hi Matt,
I have no idea about Unity, but exporting a Terragen terrain for any other 3d package is very problematic.
The microexporter mesh is mostly unusable for me.
1 - The mesh is 'just' a disconnected triangle soap, and so far I never find a way to clean it up. Polycount need to be high for good result, and merging such big file takes ages.
2 - To have a good export (close to what we have in Terragen render), the polycount need to be insane. Dont expect any good result under 8-10M of triangles for middle piece of terrain, my best one was about 30M, file size 8gb. Not many software can deal with this kind of data, and .obj is probably the slower one, or at least the less compressed possible format.
From my pov, enhancing the micro-exporter would be awesome.
1 - a merge vertex option, of course the faster the better.
2 - a decimation/poly cruncher reduction tool that will light up the resulting mesh without loosing too much detail. (very optionnal)
The number 1 is very important. If the mesh is 'clean' (no holes or disconnected vertices), we can eventuelly use external decimation tool (atangeo balancer is very good) to reduce the data. Then it's quite easy to auto-create a clean low res version in zbrush (with uv's), and eventuelly bake the details from the hires model as normal, displacement, or vector map.
As for textures, that's a very tough one. What about storing the data as vertex map ?
If you use a format like .abc (alembic), it's possible to store multiple vertex data channel (called custom channel). So it should be possible to store diffuse, spec, gloss by vertex. It's not as clean as bitmap texture, but it doesn't require uv's, and the expected tessellation been insane anyway, I think the result might be very great.
Any 3d package with a good .abc loader can then use this data to reshade the model, either by using the embedded colors, or by remapping them with custom gradients. Without saying .abc 'otawaga' compression can help a lot with huge data.
Cheers.
Proper support for vector displacement maps for object displacement would be wonderful! especially as per object displacement is on the horizon. I like Michaels idea of vector displacement output for terrain as well.
I realized that I did not really respond to matts question in my post.
QuoteWhat would be the ideal format/method for getting terrain into Unity and Unreal in your opinion?
Matt,
For me it is not about going to Unity from TG. Its about going to other soft first. The workflows I have found and am trying to learn use soft I don't have. My main problem is that I cant translate the workflows because the soft I do have dose not do the job. However, if I can skip some steps by getting the maps that I need right from TG, then I can use the soft I do have just as well as the people in the tuts, and I think, even better.
In terms of why TG would be great for a game world workflow. Just watch some tuts on how people use MUdbox/Z-brush Vue and WM/GC/other to create terrain. My point is that TG would fit in there great, because it could be used to create stamps and stencils very quickly...
It already can now! But only if you have the right soft. IF you add vectDip then TG would allow me to skip a bunch of steps in the workflows I have seen and get the same and even better results faster with the soft I do have. then once in the soft I have, I can make maps for unity.
On the other hand, I am sure that going right from TG to unity/UDK would be a good thing too. In terms of which maps are best, Well it seems to me that the maps are standard. And TG does those, but with a lot of issues.
What I would like is somehow, to get as much fine detail like in the micro exporter, but in maps.
The micro exporter is great for a few things, really great. But as Paq said, limited use. And without Z-brush, then I really need vectorDisplacement from TG to do the same job.
The power would really make such a difference for me, for one. There are some things in TG I think I will never fully understand. But those things can be done in different ways with other soft as you and everyone knows. I would like to take my TG terrains to other soft and then bring them back for rendering! Or go to unity UDK to put them in a realtime so I can play with them in VR.
About the micro exporter,
If you turn off (i think it is ray trace) then you can get very fine details, even plants and stones. This is really great for a lot of things. And I really like how easy it is to render out an object. Making maps in TG is not so easy. and you do not get close to the info in a map that you can get in an object. And then there are all the problems that Paq pointed out too.
thanks.
Quote from: Matt on April 21, 2015, 11:28:38 PM
....
What would be the ideal format/method for getting terrain into Unity and Unreal in your opinion?
Matt
According to the Unreal site it should be .fbx 2014 for meshes.
And as far as I understand there is nothing in such an engine unless you put it there.
So one would need a mesh first to have something to displace (vector or traditional).
Correct me,if I'm wrong,please.
I have only seen people making their terrains in other soft (mud, z, WM, ect) then going to unity or UDk.
Thanks for the feedback, all of you.
I will work on improvements to the Micro Exporter. The first priority is not having the disconnected triangles, i.e. vertex merging.
Quote from: paq on April 23, 2015, 12:43:19 AM
1 - The mesh is 'just' a disconnected triangle soap, and so far I never find a way to clean it up. Polycount need to be high for good result, and merging such big file takes ages.
2 - To have a good export (close to what we have in Terragen render), the polycount need to be insane. Dont expect any good result under 8-10M of triangles for middle piece of terrain, my best one was about 30M, file size 8gb. Not many software can deal with this kind of data, and .obj is probably the slower one, or at least the less compressed possible format.
From my pov, enhancing the micro-exporter would be awesome.
1 - a merge vertex option, of course the faster the better.
2 - a decimation/poly cruncher reduction tool that will light up the resulting mesh without loosing too much detail. (very optionnal)
The number 1 is very important. If the mesh is 'clean' (no holes or disconnected vertices), we can eventuelly use external decimation tool (atangeo balancer is very good) to reduce the data. Then it's quite easy to auto-create a clean low res version in zbrush (with uv's), and eventuelly bake the details from the hires model as normal, displacement, or vector map.
Yeah this is the problem I've encountered too. Vertex merging will probably reduce those sizes to about 1/3. As you pointed out, the merge step can take ages in other packages, and it's a necessary first step before you can do other good stuff like decimation / poly-count reduction, compute vertex normals etc. So, I hope I will be able compute the vertex merge reasonably quickly in TG before the file is written to disk. A certain amount of decimation in TG might be possible too, to shave some more off those file sizes before you send them to another package.
Quote
As for textures, that's a very tough one. What about storing the data as vertex map ?
If you use a format like .abc (alembic), it's possible to store multiple vertex data channel (called custom channel). So it should be possible to store diffuse, spec, gloss by vertex. It's not as clean as bitmap texture, but it doesn't require uv's, and the expected tessellation been insane anyway, I think the result might be very great.
We will investigate per-vertex colour, spec etc. But if you have to decimate your model to work with it, you'll also lose detail in those channels. Still, it will be good for the cases where you can work with the resolution.
Quote
Any 3d package with a good .abc loader can then use this data to reshade the model, either by using the embedded colors, or by remapping them with custom gradients. Without saying .abc 'otawaga' compression can help a lot with huge data.
Are these packages that many users will have, or is this furthering Badger's problem of having to go through too many different pieces of software to get where he wants, or does this work with the major modeling/sculpting apps? What is 'otawaga' compression?
Thanks,
Matt
Hi Matt,
Great to hear about the possible micro-exporter improvements !
You are right about the decimation, it will also reduce vertex channel resolution.
Maybe we can use a lowres/hires backing strategy later on in an external 3d software.
.abc is starting to be common in many package, but it's still a young format.
There is a list of software's 'ready' for it on the alembic wiki :
http://en.wikipedia.org/wiki/Alembic_%28Computer_Graphics%29 (http://en.wikipedia.org/wiki/Alembic_%28Computer_Graphics%29)
I've read Blender is on his way, but I haven't investigate that much.
My only experience with custom channels are in Clarisse (works fine) and Modo (doesn't work).
Realflow use this format (+ channels) to transfer liquid simulation data into the mesh sequence (velocity, vorticity, etc ...)
HDF5 and Ogawa (sorry for the Otawaga mistake) are 2 'compression' options often avaible in .abc exporter.
I call it 'compression', but I don't really know what's behind the scene.
HDF5 is supposed to be depreciated, and 'we' should to use Ogawa now. Loading time are supposed to be much faster (up to x25),
and file sizer smaller (5-15%). But I don't know if this number can be applied for 'single' mesh export (.abc first purpose is animation sequence transfer using
a point cache system)
Maybe you should also consider or even prefer .fbx
.fbx works for vertex data transfer (but I don't know if multiple channels are supported), it's for example the way to export/import vertex paint data from zbrush into other software's.
Mudbox can load .abc (with a external converter), but not zbrush ... and this 2 sculpting softwares could be a target of choice for terragen terrain export, as they are supposed to deal with high polycount models.
Quote... and this 2 sculpting softwares could be a target of choice for terragen terrain export, as they are supposed to deal with high polycount models.
MudBox does not like tris. It can deal with them simply being there (for painting) but sculpting with tris in mudbox, you should just give up now :-[
Hi TheBadger,
Well I'm not very familiar with Mudbox, but M2014 seems to come with auto retopology tool.
https://www.youtube.com/watch?v=cpVCvgvzR_I (https://www.youtube.com/watch?v=cpVCvgvzR_I)
Somehow it would be the same workflow than working with a 3d scan.
You can auto-retopo the mesh (terrain) into a 'low' quad mesh, and reproject the details as true geometry (surface subdivision), displacement, vector displacement or normal map.
Do you think there is something wrong with this method ?
QuoteQuoteDo you think there is something wrong with this method ?
Yes, that is true. But running retopo on a TG object? At scale to boot? I am not even sure it could work if the verts are disconnected, never mind the huge size. I have tried to open a TG object in Mud, it did not show up. I have seen people retopo dense scans like you say, and that looked cool to me. But I have not gotten a giant TG object to work.
Well, like with everything else, I guess it depends on your preferred or available soft. Z-brush users can skip all this as Chris does. But it wont work for me.
I maintain that the best solution is for TG to produce Vector displacement maps. As far as sculpting goes, then this makes it possible for TG/Mud users, and faster and simpler for Z users.
Its very important to get 1:1 results! What makes TG so great in the workflows I am after, is that I have not found a faster way to create real scale terrain. With DEM and heightfeilds plus the standard TG tools, you can get a pretty awesome terrain to take to sculpt very specific features on. And then from there, go back to TG or any place else.
Unless someone can tell me about a limitation of vectors that I have not seen yet? Probably there is one and its not really "perfect". But I just don't know what that is yet.
Quote from: TheBadger on April 29, 2015, 04:34:44 PM
I have tried to open a TG object in Mud, it did not show up. I have seen people retopo dense scans like you say, and that looked cool to me. But I have not gotten a giant TG object to work.
Have you got it to work with low-detail objects from TG? Something that is just a few Mb? So we can identify whether the problem is the file size or something else.
Remember that micro exports are in world space, so you need to recenter your view on the object (I'm not familiar with Mudbox to know whether that's automatic or not).
Quote
I maintain that the best solution is for TG to produce Vector displacement maps. As far as sculpting goes, then this makes it possible for TG/Mud users, and faster and simpler for Z users.
...
Unless someone can tell me about a limitation of vectors that I have not seen yet? Probably there is one and its not really "perfect". But I just don't know what that is yet.
Terragen's renderer is built on the idea of rendering terrains using vector displacement of a flat surface such as a plane (or large smooth object like the planet). We should be able to export a rasterised map of this displacement, along with a plane (or a low-res mesh of a section of the planet). We should also be able to export a low-res mesh of the terrain with UV coordinates and high-res vector displacement maps. Colour maps too, etc.
I plan to add a feature to do this in future. It could be an extension of the Micro Exporter, but it might be better as a new dialog that helps you through the process.
As to limitations... from my point of view, what might be a problem is the resolution of the maps. If you have a displacement that really stretches some parts of the terrain, then the textures will need to be much higher resolution in these areas. This stretching happens very often in TG scenes because the renderer adaptively subdivides the stretched surfaces and keeps producing detail because the shaders are procedural. The renderer encourages you to do things which might be difficult to transfer with simple meshes and vector displacements.
I might be exaggerating the importance of that problem. It might be something that artists are used to dealing with. But I know from analysing Micro Exporter exports that people have sent me over the years that Terragen setups can produce some insanely twisted, overlapping surfaces, often without the artist realising that's what they've done. This isn't helped by the fact that we can download other people's clip files, not always knowing how they work but admiring the images they produce, then combine them in new and interesting ways. That's works in Terragen, the renderer just eats up the displacements and renders whatever you throw it at, but exporting those kinds of assets can be difficult if you need a 1:1 round trip.
Anyway, in many cases this will work well, but there are some limitations I'm aware of.
Matt
QuoteHave you got it to work with low-detail objects from TG? Something that is just a few Mb? So we can identify whether the problem is the file size or something else.
Remember that micro exports are in world space, so you need to recenter your view on the object (I'm not familiar with Mudbox to know whether that's automatic or not).
I will retry everything tonight so it is fresh in my mind, and I can answer any specific questions fully and correctly. Is there anything else you would like me to do so you know the result?
But I am pretty sure the problem is not far clipping or camera position. Though that can be an issue, I just dont think that it was the issue with TG models. But since you asked now I feel not so confident :P I will make sure for the sake of good info here :)
Thanks for the extra info, Paq.
The Micro Exporter can write to FBX already, in case you didn't know. It would be great if vertex colour data could be standardised in one of these formats, then I would know what to support. PLY is another format that allows per vertex data in arbitrary channels.
Alembic seems like a good bet. We already have intentions to support this for full scene transfer to and from Terragen in future.
Matt
Hi Matt,
That would be awesome 8)
Here's a little test of micro exporter in Clarisse, probably the only software I know that can eat this kind of insane geometry, with full interaction in the viewport.
Actually the main problem is not the polycount, but the loading time :)
Textures was just done with 2 or 3 occlusion shader ... I can't imagine how cool it will be with Terragen textures.
(I didn't know for the .fbx, thanks)
Cool. Was this an FBX or OBJ? How long did it take to load into Clarisse? Does it look like that in realtime, and how fast is it to navigate?
Matt
Hey Ulco, sorry we have hijacked your thread!
Hi Matt,
It was using the .obj format.
Loading time is about 360 sec, + an other 350 sec to build the acceleration structure. (.obj size is 6.8Gb) ... but Clairsse give the hand back after the initial loading.
The image posted is a 'render' image, takes +- 8 min to render on a 6 cores cpu, with brute gi and a volumetric fog for the atmosphere (gi in desactivated on volume for this scene).
Scene interaction is very responsive ... you can manipulate the object in the 3d view with ease (gray shade mode, but it's still the render engine in fact)
You can duplicate the mesh like it's a simple cube.
I would probably never build a scene with a mesh like that, but importing multiple pieces of terrain of 4-8 gb is very doable on a low-end workstation .
QuoteAs to limitations... from my point of view, what might be a problem is the resolution of the maps. If you have a displacement that really stretches some parts of the terrain, then the textures will need to be much higher resolution in these areas. This stretching happens very often in TG
If I can get the TG terrain into a vector map (by any means) than I can use it as a vector stencil. Once as a stencil I can retopo the result and go on like that making more and more complex vector stencils. Then at at end, Make a plane to project to, and make a vector to go back to TG with. In this way, stretching may be addressed down the pipe.
I will try to do as paq suggested with retopo-ing the TG .OBJ now. I am waiting for the object to render out. I think It will not work, but I cant remember exactly why. But maybe It will will if I had been doing something wrong.
Paq's argument about retopoing scans is a pretty good argument. Not exactly sure why it would not be the same with a TG obj... I am still guessing verts and scale, but...
Hi TheBadger,
Well I was talking about retopology, but as a matter of fact I don't think I will even try that in zbrush if the mesh is too big (over 3-4M of tri's)
I will just use the zbrush dynamesh tool, that basically voxelize and re-mesh the object. It's a much faster than a retopo procedure, less clean (there will be lots of triangles and quads), but good enough
for sculpting.
For mudbox, as Matt said, the input mesh should probably more in the mid-res area, maybe don't exceed 1 or 2M of triangles at first ... disconnected triangles might be a problem for the retopo tool.
My advice about vector displacement is that it works well for ... displacement, but mixing displacement and bitmap texture is always a little bit cheesy.
It's like height map, high slope in the elevation = less definition. So for the color textures (diff, gloss, etc), using low-res model as 'origin', like Matt said, is probably a good idea (as opposed to 'from a plane'). But uv's from this mesh need also a little bit of care, like relaxing or auto-pelting to get an uniform texture result ... sounds very very tricky to me.
That's said, a 'one click' vector displace export from Terragen can be handy as it is, just compute from the orignal plane(t). It could be used to create really impressive brushes for Z-box !
Hey I went through somethings. I remember now.
it does not mater at all what is wrong with the object or what is right with it. The only way to get a one to one result from TG in MUd is Vector. There is only one way to project the object to a plane, and that will not keep overhangs, and it will not give you one to one results.
Vector is the only way to get an exact replica of a TG terrain in MUd. That is other than a TG obj, but then even if it opens, and you can project it to a plane, you will just get the same results as a height map. And you have to deal with a huge object and memory if the object is to have any detail, that makes it better then a heightmap, like if you render with Raytrace off, to get super details like stones.
I did mange to get a TG terrain into mud via Maya, by a heightmap. But this does not give a 1:1 result. A good way to start a raw sculpt, but then why use TG at all in that case, it is not really a plus.
THe thing is, if I am not getting the work I did in TG to go to mud, then there is not really any point in doing that work in the first. So low res is not a solution. I can make a low res terrain in Mud in 5 seconds. I want to take lots of info, so I dont have to sculpt it.
Quotesounds very very tricky to me.
Sounded that way to me at first too. But its pretty simple, if repetitive. Only two softs needed. And the work flow is basically proven already, just in parts. Vector would bring it all together now.
Now here is tonights effort to get the object into Mud, just so you can see what happens.
The object imports in the normal way, and this warning pops up:
[attach=1]
I then hit "keep all"
And get this:
[attach=2]
Spinning wheel for a while...
Force quit.
Object size was 1.2GB pretty low quality/rez.. IT opens in maya just fine though, can even move around pretty easy. So that should tell us something.
[attach=3]
Oh, one more problem with obj from TG...
So even if you are doing a low res starter mesh to use in another soft, you have to tilt the camera so that it is not straight down. This means that some part of your object has missing parts. As apposed to a height map from tg, which catches everything (within its limitations).
Matt,
Thank you much for delving into this in the open!!! I remember that you said that it would take a lot longer to get per object displacement, and then out of no where we are getting it! I hope that will be the case here too (that vector will come sooner than believed), I really need it.
sadly, I have mostly stopped using TG, I have reached the limits of my abilities to understand it. And I need to use other soft that I understand a bit better to accomplish some of the same things that others can do with TG alone. For example, some of the shapes that people make with functions, I will never be able to do. I can however do that by sculpting them (or painting or whatever). I kinda think about it as way to make any sculpter a plug-in to TG ;D, no plug-in required.
Hmmmmm, a "go Z", go Mud, button in TG? ;) Well that would be fun anyway. One of the SDK alphas should try that 8)
QuoteHey Ulco, sorry we have hijacked your thread!
No worries; this was just my intention, getting you guys to think about how to export the terrain data from TG for use in other software. Just as a sidethought; photogrammetry from inside TG would probably also work, but a LOT OF WORK; rendering views from several angles, and combining them to a 3D mesh. Strange workaround.
Quote from: Dune on April 30, 2015, 03:21:36 AM
QuoteHey Ulco, sorry we have hijacked your thread!
No worries; this was just my intention, getting you guys to think about how to export the terrain data from TG for use in other software. Just as a sidethought; photogrammetry from inside TG would probably also work, but a LOT OF WORK; rendering views from several angles, and combining them to a 3D mesh. Strange workaround.
"photogrammetry from inside TG would probably also work"...that is a delicious thought...should be not that hard to implementmaybe 5 camera shots; N.S,E, and W and a top down...I vote for this as an update, hee hee hee.