Script based export and questions

2378
1
03-04-2012 03:54 PM
RobertHexter
New Contributor III
Hey guys,
I'm evaluating CE currently for use on a project, prior to our purchase.
I'm needing to setup a pipeline that looks very similar to the UDK export instances one that I've found from the old Proceedural site in Googles cache.
Okay, so being on the trial I can not access the export functions to try them out ( a key part of my evaluation) :(

Anyway, I have setup the reporting cga rule from the old example,
I generate a building
I look in the inspector at the reports section and it contains the information I expect to see, YAY!

Now to Python

Question:


sel=ce.selection()[0] #gives me a shape 'sel'

sel.getReports()['asset'] #suggests that the Shape object returned has a getReports method that generates a dictionary, no?
reportDict=sel.getReport() #I get no return from this at all.. yet the shape does have report data displaying in the Inspector I certainly don't get a dictionary returned?

sel.getReport().has_key('asset') #causes city engine to lock up, it never comes back so I have to kill it, I guess this should not happen?
sel.getReport(). #is where it locks up as soon as I hit the 'g' key to enter 'get_key'





SO these are things I need to evaluate, I need to look at the data that I can generate, obviously without access to the exporters, however this is not appearing to work, is this buggy trialware only?

Question
I see the following demonstrated in the examples from the old pages:

using an instance of the class Model

model=Model(modelUUID)

Can Model be used within the city Engine python script Console?
Is 'modelUUID' the equivalent of the 'shapeUUID' that I can return from my shape I generate within the City Engine? 


Question
I find no mention of using Class instances in the APi docmentation, is this possible, being a standard part of python?

Question
I assume you are using module based globals within the exportInstances.py script examples to pass data from one function to another?
i.e. one catalogs as the exporter iterates through shapes in the scene and the other uses the data gathered and runs the finishExport() after the export process has completed

from finishModel() to finishExport()

I assume that finishModel() is always run before finishExport()?

Am i able to use Class Instances that contain more complex data structures within the global scope of these export scripts?

Question
Am I able to run both and fbx export for unique geometry as well as handle instances as described above in one export step or is is a case of having to run multiple export steps to extract specific data from the scene at each export step?

SUggestion/Comment
How do I tear off windows? this is very annoying everything being docked?

Are you going to be moving this to be more pythonic ie object orientated?
shape=ce.selection()[0]
shape.getAttribute('height') # is more intuitive than current

ce.getAttribute(ce.selection(), 'height')
Tags (3)
0 Kudos
1 Reply
AndreasUlmer
Esri Contributor
Okay, so being on the trial I can not access the export functions to try them out ( a key part of my evaluation) :(


Please contact your local Esri office and ask for a time-limited full version for evaluation.
http://www.esri.com/about-esri/locations.html




sel=ce.selection()[0] #gives me a shape 'sel'
sel.getReports()['asset'] #suggests that the Shape object returned has a getReports method that generates a dictionary, no?

...

model=Model(modelUUID)

Can Model be used within the city Engine python script Console?
Is 'modelUUID' the equivalent of the 'shapeUUID' that I can return from my shape I generate within the City Engine?  



getReports() ONLY works on models in the script-based exporter context. There is no way to access reports via Python without the script-based exporter callback functions.






Question
I find no mention of using Class instances in the APi docmentation, is this possible, being a standard part of python?

Question
Am i able to use Class Instances that contain more complex data structures within the global scope of these export scripts?

-----

Question
I assume you are using module based globals within the exportInstances.py script examples to pass data from one function to another?
i.e. one catalogs as the exporter iterates through shapes in the scene and the other uses the data gathered and runs the finishExport() after the export process has completed

from finishModel() to finishExport()


The easiest way to share data during the export context is to use globals in the callback script. You can use custom classes for this if desired.


Example.
class MyClass:
    n = 0
c = MyClass


def initModel(exportContextUUID, shapeUUID):
    ctx = ScriptExportModelSettings(exportContextUUID)
    shape = Shape(shapeUUID)
    global c
    c.n = c.n+1
    print c.n




I assume that finishModel() is always run before finishExport()?


The script-based export callback functions are executed in the following order:
# Called before the export start.
def initExport(exportContextUUID):
    
# Called for each shape before generation.
def initModel(exportContextUUID, shapeUUID):
    
# Called for each shape after generation.
def finishModel(exportContextUUID, shapeUUID, modelUUID):
    
# Called after all shapes are generated.
def finishExport(exportContextUUID):





Question
Am I able to run both and fbx export for unique geometry as well as handle instances as described above in one export step or is is a case of having to run multiple export steps to extract specific data from the scene at each export step?


There seems to be a word missing in the question. (run both ... and fbx export). Could your reformulate this question?



SUggestion/Comment
How do I tear off windows? this is very annoying everything being docked?


pick and drag the tab of a window outside the main window.
Note that Editor windows (Scene, CGA Editor, Python Editor) can not be detached.




Are you going to be moving this to be more pythonic ie object orientated?


When the Python API was first introduced, it was designed to work it in a similar way to CGA scripts. Therefore simple function calls were preferred over OO concepts. With the growing feature set of the Python API we might need to reconsider that decision for future releases.
0 Kudos