TG2 v2.4 64 bit Mac TGO writing issue

Started by jo, June 05, 2012, 02:24:03 AM

Previous topic - Next topic

jo

Hi,

We've found a bug when writing TGO files using TG2 v2.4 running as 64 bit on OS X. When you load a TGO file written using that configuration you may find that there is missing geometry.

There are two workarounds:

1) Save the TGO files using TG2 Mac running in 32 bit mode. It's easy to change TG2 Mac between 64 and 32 bit mode:
- Select the application in the Finder and do a Get Info on it (command-I hotkey).
- In the General section of the Get Info window you'll see a checkbox called "Open in 32-bit mode". Check that checkbox.
- Start TG2 and it will now run in 32 bit mode. You can tell this is happening because the System Information part of the Splash Screen and the About Box will say "32 bit".

When you have saved the TGO files you can start TG2 in 64 bit mode again by repeating the steps above but *uncheck* the 32 bit mode checkbox.

2) To save changes you might have made to materials you can save the object and any associated nodes as a clip file. Your model will stay in its original format (OBJ for example) but the changes you've made will be saved with the clip. Simply select the nodes you want to save in the network view and then context click on one of them. Choose "Save Nodes as Clip File..." from the context menu.

This problem will be fixed for TG2 v2.5.

This problem does not effect the Windows version or the 32 bit Mac version.

Regards,

Jo

TheBadger

It has been eaten.

TheBadger

Hi jo,

I have been building and working with objects a lot lately and have run into a new issue, which may or may not be related to the .tgo problem.
I have been seeing the same missing geometry in objects without converting to .tgo, that is, while still .obj.

The problem seems so far, to be only in objects that are used as a population, and only when ray trace objects is turned off. I can not yet say for sure that this always happens in all cases, but it is often enough to be a problem.

It does not appear to be a problem of placement of the light source. I understand that light behind displacement can be an issue, is that correct? At any rate, the light source does not seem to be the problem.

Is this news to you? Or am I not remembering a previous topic on this?
It has been eaten.

Oshyan

I haven't heard of a problem like that, nor of any issue with "light behind displacement". If you have a TGD that can reliably reproduce the problem, please send it to the support address along with the object(s). You can use the "Email large files" site that Hannes posted recently if you need to (I've tried it, it works great!):
http://www.planetside.co.uk/forums/index.php?topic=14607.0

- Oshyan

TheBadger

#4
Hey guys.

Its definitely not the file. It happens in every new file I try. It must be my models, or TG. I can send you some models to try it with Oshyan or jo. I'm a little sad that no one else has reported this. That indicates that its likely my models:(
Its funny, because I can see that geometry is missing even in the 3d preview window
I am rendering a very high quality image from the project now. I want to see if that takes care of the problem.

I have been using Hexagon2 for my modeling. That program has some issues to it. I hope its them and not tg or me;)

Oshyan, sorry. To be clear, I meant to say the problem was not related to the sun being behind terrain, not displacement. That is, light is not shining through objects, but the objects are missing parts.

[attachimg=1]



[attachimg=2]


*the objects in the images showing the problem do not have displacement added in TG2


It has been eaten.

Oshyan

It would be great if you could send us an example model that shows this problem and details on how you created the object file, including any additional processing you did (i.e. Poseray), along with a TGD and any particular steps to reproduce the issue. You can send the files to support AT planetside.co.uk if they're under 20MB, or we can arrange for transfer of larger files.

Thanks,

Oshyan

TheBadger

Sending via www.wetransfer.com 16% so far. Please confirm when you can

Thanks guys.
It has been eaten.

Oshyan


dandelO

Badger, are you using the quality drop-down options in your populations? If you are not and you aren't using RTO, then you should.
I remember populated objects looking very degraded like this before RTO was around. Each instance in the population is optimized, try; High, V.High or Ultra quality in the population node. I also remember when I made the windy trees thing that the highest quality setting for non-ray-traced objects was actually quicker to render, I'll try and find the thread...


dandelO

Just to update about Badger's problem...

First is a population at default, 'Medium quality'

[attachimg=1]

And here is the very same but set to 'Ultra quality (slowest)'

[attachimg=2]

I think that's just the problem you're seeing here with the missing faces.

* 'Ultra' was, again, 1/4 faster to render. Weird but good.

Oshyan

dandelO, we more or less came to the same conclusion, although it's particularly bad in his case with these specific models. It may have something to do with the very high geometry density. We're continuing to look into it.

- Oshyan

TheBadger

Thanks DandelO!

I am applying the information to my project.

On the subject of my models... Oshyan, I realize the models are rather noobish. And I have been getting better at modeling. But as far as this issue goes, what do you recommend I do from now on? Is it just a question of reducing polly count and/or further simplifying my forms? Or...?
It has been eaten.

Oshyan

Actually, I think the models look quite nice. I'm not a modeler myself so I can't reasonably critique them in terms of their construction, but the end results are very good in my view.

I don't think that you've done anything necessarily "wrong" in your modeling, either. The quality settings in non-RTO rendering are there to help strike a balance between render time and quality. Non-RTO rendering just isn't as fast at rendering high quality objects. If you *must* use non-RTO and the issues only occur in a population, then just use high population quality. If the issue occurs in single objects, I don't know if making it into a population and reducing it to a single instance through population controls, then setting it to high quality would help. I think the less complex your objects, the less likely problems are to occur, and perhaps if you add more detail in through displacement (with RTO *off*, of course) and less through actual geometry, that also would help, but I'm not sure of that.

- Oshyan