Software dead end. (fixed)

[TheBadger]

I have found that there is a lot of power in TG that comes from using other software in combination with TG. But as I experimented and tried various things I found that when trying to go *from TG* to other soft, success really depends on what other soft you have.

For example, the power of Z-brush and TG (with a little Maya) is freaking awesome! really it is. And that awesomeness is repeatable if you have Mudbox instead of Z. But this is only when going from the others to TG. When starting in TG, then there are lots of problems if you don't have the right software. I pestered chris_x422 about his workflows when starting in TG. He even gave me a step by step guide of how he does it! And I had hoped to translate it for Mudbox since I don't have Zbrush. The problem is, that Mudbox is not Zbrush. Not even close as I have learned the hard way. It can't be done in MUD.

I have managed to work out what I feel is a super fast and powerful *from TG, to* other software workflow. That for *me* is totally ideal for how I want to work. With this workflow I can do all the things I really ever wanted to do. I know all of the parts of this workflow, all of the things I need or want to do in all of the software that I have for it. But there is one big problem. I cannot connect TG in that pipeline the way I need to, to get it to work. I don't have the right software, namely Z-brush.
I even spent a LOT of time on workarounds like using more intermediaries, namely GC2. GC2 totally sucks on OSX. Dead end. And just like I don't have Z, I don't have WM, so could not try that. 3Dstudio Max would maybe work too, because it apparently can read .TER. But I don't have max or windows, and .TER I have found, can be highly problematic anyway, depending how you built the terrain that you are trying to export. (again, just when going from TG. To TG is pretty smooth).

Other than me spending 800 bucks on Z, which I can't now. There is one thing that would work well enough if TG could do it. Export maps... Now I cry

Just like a micro exporter in the top down, except instead of geo, you get maps. Maybe a Vector would be great. But a simple (high quality) grey scale displacement map would be enough I think. At least I know I could work with that. Basically a height map in a readable format for other software.

Why would I start in TG anyway?
Oh man! there is no faster way that I have seen anywhere, to get so much so fast. Just get a DEM, use a SSS mask and a vertical adjust, and a hand drawn Image mask for major specific shapes to cut in with. And Oh man! add the power of sculpting to that and function nodes can eat me. And that's just if you want to keep it simple... Which I don't!

But really, having worked all this out step by step (all the part with the soft I have), its about speed and ease. The creative power should be obvious.

But now here is my question/complaint. If TG can export a super high detail real scale .OBJ of a terrain Via the micro export. Why cant it simply make a surface map of that terrain?!
Also, People have been asking for this, or similar for years. And I ask this with all humility in awe of what programmers can do and how much work it to make something great like TG. But why don't we have the ability to export maps of our terrains yet?

PS
World creator may be a fix. I don't know. Its one of the prizes in this years contest. Looks like good soft. (OSX compatible, WM is not) And it is cheaper than Z-brush. It may be possible to go through it to mud as some use GC and Mud in UNITY workflows. Hard to say. But anyway, TG exporting maps would be the very best thing.

[Tangled-Universe]

Did you try exporting a heightfield using the heightfield generator? You can save that to a .exr file, for example.

[TheBadger]

Yes. You mean .TER right? Then yes. IT can have lots of problems depending on how you do the terrain.
For example, I used a DEM with some general terrain features that I was after. I masked that out with an sss, to control the amount of area, and then moved the XY to put the best area at 000. I also then added a vertical adjust. Some image maps and some other things.

It did not work to save a TER very well. What I got was not even close to what I was after. And even if it were, It was really difficult to get to show right in GC2. The problem is that its so unresponsive that I could not really even try to figure it out from that end. but it looked completely wrong; scale ,shape, everything.

I am trying to work within the problems as I understand them at this moment. But I would have been done days ago if things had worked close to how I had hoped.... I redid the the whole thing in a number of different ways a few times. As a result I am further along in TG, but that was not my intent.

Hmmm, your questioning me made me think of something else I could try. Have to wait till tonight though. In the meantime Ill read whatever you or anyone wants to say about this. I won't discount the possibility that I did everything wrong. But I did what people said I should.

Still, wish we could save maps. But I know its a little strange that I would get pissed that a terrain program does not make surface maps. 

[Dune]

It's not that hard to make a greyscale map from the TG terrain. I got a GIS file with a lot of artifacts a while ago, which I loaded like you load a GIS file (color by shade), then put the camera on top, straight down, cropped the area I needed, and rendered a 16-bit tiff out of it, which I could work on in PS.

Or in case of a TG terrain; added a distribution shader where I figured out the max height and fuzzy zone, so I made the highest white and lowest areas black (you can use camera+distance shader as well). No sun, etc, then render in high quality.

Or did I misunderstand your problem?

[TheBadger]

Sounds like you get it just fine. And that may be a useful method Ill try it. But I hope you also agree that that is neither better nor even as good as getting a proper surface map? I mean its going to be a lot of extra work. And it wont be really the same. But yes, that is a good tool in general and Im glad you mentioned it here.

[Oshyan]

I'm surprised that even Ulco is not using (or aware of?) the terrain export option Martin mentioned. Ulco, why do you go through all that hassle when you can just right-click a Heightfield node and choose Save As and get a proper, uniform detail, standard heightfield?

It seems you know how to export TER, right Badger? (as above) Martin is saying (correctly) that you can also export EXR format in the same way. I don't think that will help you at all with any of the other terrain editing software since I doubt any support EXR, but it sounds like those were intermediaries anyway. Mudbox *should* be able to read EXR though, and it may help with your issues with workflow. The only thing I'm not clear about is whether you're asking for *texture* output (which TG does not do), or *terrain*/heightfield output. If it's the latter, you already know it *can* do that in TER, I don't know what problems you've had trying to use that format, but EXR may address them. It's the same export process.

The only other thing to be aware of - and I guess maybe it's why Ulco doesn't use normal heightfield export - is that to get a *procedural* terrain out of TG it takes just 1 extra step. Since there is no Heightfield to right-click and save as in that case (e.g. you are trying to export a section of a Power Fractal), you have to add a Heightfield Generate. Then connect the output of your procedural terrain network to the Shader input of the Heightfield Generate (on the right-hand side of the node). Now setup the size and coverage area parameters in the Heightfield Generator and position it over the area you want to export - remember, it can only export a finite area at a finite resolution. The resolution is in pixels, the area covered is in meters, and will be visible as the Heightfield Generate bounding box in the 3D preview so you can position it correctly. Use more pixels for higher resolution/detail. And remember, it can't export non-planar features (e.g. overhangs).

That being said, EXR is not going to have scale info built-in to it like TER will. Mudbox and Zbrush can't read TER anyway so maybe it's a moot point. But at least you can use the scale info in TG to base your setup in Mud or other apps off of.

I hope that helps. It sounds to me like TG already does most of what you want. If not, please elaborate/clarify.

- Oshyan

[Dune]

Yes, of course (slapping my face  ), I used that method years ago, but totally forgot about it. Thanks for refreshing my memory, Oshyan.

[bobbystahr]

With info overload I often forget face smackingly simple stuff....it happens to us all....

[TheBadger]

To be honest. I saw that .EXR was an option but did not understand that it was another way to do the same thing. Of course now that you brought me here I realize that .EXR is how I bring stuff into TG (per OP post) So now I see that I should think the same when going out from TG too.

Sorry Martin. I did not understand that you were talking about the same thing when you said EXR and heightfield in that post. I kinda just thought you were listing things generally related to the main idea.  Well OK then

I am working on it all now. Hope I can get through this last bit of issues.

[TheBadger]

None of this works at all. The .EXR is basically void of any information, just black. And a .ter does not show correctly in GC (though I am not good at GC, due to it being so unresponsive on OSX) But maybe the way to connect the nodes is wrong.
[attach=1]

the Heightfield Generate bounding box in the 3D preview so you can position it correctly.

No. I don't see that happening anywhere. I get no bounding box at all

Another thing I could do, since the terain OBJ opens in Maya just fine, is make a height map there. But the instructions I found are pretty confusing. Again, the best possible solution would be to have the micro exporter export the map, ideally a vector. But Just a proper height map would be great too. THis would also make the Zbrush flow better as well, since you would not need to import the terrain into Z to make a projection.

A 1:1 result is what I am after here. I just need to make this darn map from TG. I can work at scale in MUD, but...

The problem with the Mudbox translation of the Z-brush workflow, is that Mudbox freezes when importing the  terrain obj. But there are warnings before that:
[attach=2]

Ignoring the warning then starts the import, which freezes mudbox. Force quit is the only way out.
However, I can create a plane in maya at scale and import that, then sub d, then sculpt just fine.

I am not sure how big of a terrain you can import into Z-brush. But the only reason to import the terrain anyway, is to make the map projection. IF I can get rid of that part of the flow, then I can do this. The only part I cant do so far is make the map.

What do you guys think? And sorry if the answer is right in front of me, but I just don't see it.

[TheBadger]

I found a script for Maya that automates the process of making a "perfect" displacement map, height map of an object, or objects.
Will see if I can get it, and install it.

[Dune]

What do you want to achieve anyway? Make overhangs in other software, based on your map? You can do that in TG.

[TheBadger]

The script works PERFECT!!! Solution found (still would rather that TG did this native, but I cant complain now) The quality is unlimited.

Ulco, no TG does not allow you to sculpt native, that is what I want. The difference between what I am doing now, and what we all talked about in the big vector thread is a lot really.

By using DEMs masked by sss, and raised or lowered with adjust, I can use even poor quality data to get instant results. Even on low quality (high arch) sat data, there is still a ton of detail that would take hours to reproduce in TG node by node, if not much longer. I can also set up the sss and DEM to the exact scale I want, and then mask it with a painted image map.

The great part about that is, when applying the image mask, it is different for every terrain. So I can move the DEM with in the SSS (XZ) and get huge changes in the look. The image map also looks completely different when used on any other terrain, since it was painted and changed according to the current terrain (DEM in this case)

In this way I can also use multiple DEMs to create mash ups. And then make a image map mask to create some unifying feel; canyon, flat area, river, so on.

Basically to put it short. I can do whatever the hell I want now, fast, easy, with no more punching walls Then I take it to Mud and sculpt specific details, return to TG as 1 Vector, and use more PF to texture and color.
Also these maps that the script produces are more easily used in GC2, and probably other soft (compared to TER.) In fact. There is no reason at all that game makers cant use TG more often then they do now, with this flow. Its so easy, even I can do it.

Another advantage is correct scale. I know that the canyon I am making is 100 meters high at its tallest section. I know that the canyon is 2000 meters long (2K*2K), Setting that up in TG, is easy as pie. It is however very difficult to do the same in MUd and maya... I mean to make a human perspective of the canyon from the inside, and then sculpt everything at the specific scale. Because of the way I did it, I know absolutely, that my scales are basically correct.
Now when I go to mud, all I have to do is import a plane ate the 2K2K meters, and I know that my terrain will be correct scale. I then can move through the terrain and sculpt much more fluidly than the 3D preview will allow even just to view.

As I said before, blue nodes can suck it.  Ill get my squares faster and better this way. Really except for global coverage, this is the better way to work IMO.

[TheBadger]

Just tested it. It all works. No need to buy Z now (even though I think that would maybe be better, though harder to learn).

[Tangled-Universe]

I'm still curious why your .EXR export was 'empty'?