Export hanging on "Finalizing Export"

1126
11
04-30-2013 09:12 AM
RobHoward
New Contributor
When I try to export a scene, the exporter sometimes infinitely hangs on "finalizing export."

This is a problem with a new building I've developed. It's meant to be very fully featured in terms of randomized
facade elements, attached models, texture variations etc.

The rule file has gotten very large. If I reduce it down in size by eliminating some of the facade elements and variations,
the export works. As I reintroduce things, eventually I'll reach a point in which the export starts hanging on "finalized
export" and it fails (I have to kill the CE process to get out of the program).

This suggests there is some kind of limit to how complex a rule can be if it is going to export successfully. Is this the
case? And if so, is there a way to test or know what that limit is?

Thanks.
0 Kudos
11 Replies
ScottFujikawa
New Contributor III
Hi,

Are you using the 64 bit or 32 bit version? The 64 bit version better utilizes memory so you can push up larger scale projects.
Take a look at this thread which may offer you some solutions:
http://forums.arcgis.com/threads/56490-Freeing-up-system-memory

Cheers,
Scott
0 Kudos
RobHoward
New Contributor
We're using the 64 bit version.

I tried increasing the Java memory as per that thread, although I think (from reading other threads) that java memory doesn't affect
model exporting?

At any rate, when I alter the CityEngine.ini file line (-Xmx4096M) it doesn't have any effect. The memory indicator in the lower
right doesn't seem to show any difference either, it is just under 2000 like it normally is. Is there some step involved in getting
CE to recognize the higher Java memory threshold I've set?
0 Kudos
MatthiasBuehler1
Frequent Contributor
Hey Rob,

Are you also exporting a terrain ? Check the export granularity concerning terrain exporting. Default is 'export all visible terrains' in CE 2012.

Note that in the misc tab, the default is 'simplify terrain'. this triggers an edge-collapse algorithm to process the terrain and create less polygons. this is expensive to calculate, especially of course if you have high-polycount terrain ( check also the UV-subdivisions in the terrain layer. Turning off that simplify should speed up the terrain export.

Ok ?

Matt
0 Kudos
RobHoward
New Contributor
Hello,

We've been turning terrain layers off, both in our python script and when I used the GUI to export, so I don't think it can be that.

Quickly, to kind of "reset" the thread's main question: is there some kind of limit to how complex a CGA created building model can be? Such as too many shapes broken up into component splits or something?

My memory, both Java and system, always shows well into the "green" (Java is usually at 1900 MB, and system is usually at 6547 MB).
0 Kudos
MatthiasBuehler1
Frequent Contributor
Hi,


In by far most cases, complexity is no problem.

If so, you get errors in the CGA problems view. E.g. with too many recursions.

Check also the docs on the Grammar Core's 'max derivation depth' and ~width settings.

How many polygons do you create per building ? Can you export single buildings successfully ?

Let me know ..

m.
0 Kudos
RobHoward
New Contributor
I did try making those numbers larger in the grammar core, to no effect, but I do think, after trying to find an answer for you on how many polys these models are, that I might have found the problem? Here's an export log of one of these buildings (note the errors regarding the UVs):

EXPORT LOG / CityEngine 2012.1.09130547
---------------------------------------------------

export started at: Wed May 08 11:30:59 2013
export completed at: Wed May 08 11:31:02 2013
export duration: 3.1 seconds

EXPORT SETTINGS
    format:                Autodesk® FBX® 2013
    location:              C:\hh\sol\CityEngine\City\models\test
    base name:             City_zone_E2_N1
    export content:        0 (0 = models only, 1 = fallback to shape, 2 = shapes only)
    file granularity:      0 (0 = single file (or split by file budget), 1 = file per initial shape)
    file size budget:      0
    mesh granularity:      0 (0 = as generated, 1 = mesh per material, 2 = use instances of inserted assets)
    vertex precision:      0.00100
    normal precision:      0.00100
    texcoord precision:    0.00010
    merge vertices:        1
    merge normals:         1
    merge texcoords:       1
    triangulate:           1
    reproject texcoords:   0
    vertex indexing:       0 (0 = allow shared vertices, 1 = force separate vertices)
    normals type:          0 (0 = use vertex normals, 1 = use face normals (flat))
    normals indexing:      0 (0 = allow shared normals, 1 = force separate normals)
    write texcoords:       1 (0 = no texcoords, 1 = first layer, 2 = all layers)
    write materials:       1
    collect textures:      1
    file type:             1 (0 = ascii, 1 = binary)
    embed textures:        0
    write master file:     0
    master group name:     CityEngineSceneRoot
    write cam data:        1
    batch behavior:        0 (0 = normal, 1 = skip existing files, 2 = dry run)

INPUT STATS
    number of initial shapes      = 1
    number of generated shapes    = 5515
    number of generated meshes    = 5515
    number of generated materials = 5515

OUTPUT STATS
    written files: 1
    written materials: 6
    written meshes (total polygons): 5515 (64340)

INPUT REPORT
    collected/generated initial shapes:
            0: OK    : Shape                                    OID: 65d808c7-94fb-11b4-9f79-002564ace543:4
               ERROR: Mesh::normalizeUV() : can not normalize, delta u is too small (0.000000)
               ERROR: Rule 'Default$CityBuilding.WallTextureB;' : tileUV failed (normalize)
               WARNING: Split: leaf 2 has size 0.000005, too small, ignored
               ERROR: Mesh::normalizeUV() : can not normalize, delta v is too small (0.000000)

OUTPUT REPORT
    written files & status:
            0: OK:                        C:\hh\sol\CityEngine\City\models\test\City_zone_E2_N1_0.fbx

---------------

I'm thinking the shape errors are what is causing the problem? Which basically seem to be that some of the UVs are too small? Also to answer another one of your questions, I can get single buildings to export, it fails though when I try to export in groups (usually when I try to export something larger than a single city block).
0 Kudos
MatthiasBuehler1
Frequent Contributor
Hi,

Would it be possible that you send me a PM with your mail address and you then send me a stripped-down CE project archive ( zip ), on which I can reproduce the issue ?


If it's a bug, I'll have to reproduce it here anyway.

Let me know if this is possible.

Matt
0 Kudos
KareenBröker
New Contributor
Hi Matt!

Did you ever find a solution for this?

I think I am having the same trouble with exporting my shapes to Collada 1.4.1...
Maybe there is something wrong with the shapes I am trying to export or maybe I am not using the right export settings?

Best regards,
Kareen
0 Kudos
MatthiasBuehler1
Frequent Contributor
Hi Kareen,

Well, we tested the exports a lot, but there may have been some rare cases that slipped. 😞 No software's perfect.. 🙂

But I always need very precise details to be able to help. As written in the post above, if there's a 'hint of a bug', I need to be able to reproduce it on my machine here.

So please track the issue down very precisely, otherwise it's hard for me to help ..

Matt
0 Kudos