Latest Contributions by MarekDekys

‎08-13-2019

I confirm that this issue still persists on 2019.0 and 2019.1 beta

‎08-01-2019

Hi, I'm experiencing the same problem with getRuleFileInfo() error with no further information available and this happens in newer versions as well (CE 2018.0,2018.1) This is probably because the rules are too complex and/or because of lots of linked rule files - I can confirm this, because when I turn off some parts of the code (by commenting), the other part always runs without problem I don't know about any workaround for this. The only way that works for me is to have less complex (less advanced) rules in order to to be able to use these rules at all - but this greatly sacrifices visual quality/functionality required by our customers (and also because I spent tons of hours by making the cities nearly photorealistic and now, I only can use a portion of this) I would appreciate if somebody could give me a clue on which commands are more likely to cause this issue.

‎08-13-2018

Hello, I would like to request an idea that CityEngine (.cej) scenes should be backwards compatible with previous versions of CityEngine. The reason behind this is that during a big project, we start working in let's say CityEngine 2016.1. Then, 2017.0 came out with new features in .cga code (and generally newer should be always better in terms of stability, efficiency.. etc..) so we tried it but we found out that this new version brings also some problems (for example bug in camera movement..) But if our team consists of: content creators - who don't develop cga rules but create/adjust buildings,streets... their workflow is now more time consuming because of this camera bug but once it has been saved in 2017.0, it cannot be reverted to earlier version. rule developers who can live with occasional camera bug but need the new features of 2017.0 to develop more sophisticated rules. If the scene would be backwards compatible, content creators could work happily in 2016.1 and developers with 2017.0 and when the time comes, scene is exported with 2017.0 Therefore when a new cityengine version comes out, we always cannot decide if we should use it or not - because some of the errors are detected later when some work has already been done in the newest version and there is no way back. One way to revert it back to previous versions would be to export all contents of the scene back to for example shapefiles and import them in old CE. but this migh be time consuming if we have lot of layers (have to export them 1 by 1) and is also a lossy process because it might not export all the settings (cga parameters) that were affected and is most problematic when exporting screets with all of their attributes (either object attributes or cga attributes, dimensions, curvature etc..) Alternativelly, if making entire scene backwards compatible is not possible, would it be at least possible to force let's say for older version of CE to use .cga runtime from newer version and vice versa? Thanks, Mark

‎11-08-2017

can anyone help me please? or should I provide any additional info? I finished very big project, it works great when I export a set of buildings as a single building 1by1... But when I try to export the same set of buildings (that I did 1by1) together, it crashes everytime - therefore I cannot export my work and I'm really stuck here because I have to export tens of thousands of buildings like this. thanks, Mark

‎10-24-2017

Hello, I am using a complicated cga rule on shapes (that are actually untextured 3d building models ) this rule calculates all kinds of things in order to realistically subdivide and texture these building models on input. While the output looks really nice, this rule often crashes CE when I select several buildings and generate them. The crash completely kills CE and only generates a logfile (attached) hs_err_pid<process number> which is not related to .cga rule The problem is that I cannot reproduce this crash because for example when I select 1 group of buildings and generate them it may crash during one attempt but won't crash when I restart CE, select exactly the same number of buildings and generate them again. The other thing I found out is that if I set Number of parrallel generate threads to 1 instead of default 0 - it is less likely to crash but still crashes a lot. Another weird thing is that no matter how many parrallel generate threads I use, when I manually select building by building (shape by shape) and generate only one at a time it never crashes. But I am using thousands of buildings and generating them one-by-one is extremely time and file consuming I tested this only on 2017 because I'm using a lot of occlusion functions with labels (which are really awesome btw) which is unsupproted by previous versions. Because the code is really complicated, it leaves no log on where this happend, and it happens randomly it is difficult for me to pinpoint the cause of the problem. Does anybody have similiar problem? or at least do you have any idea if there are some .cga commands which are more likely to cause this hs_err_pid issiue? I'm suspecting alignScopeToAxes, alignScopeToGeometry and innerRectangle thanks for help, Mark

‎10-10-2017

Hello, would like to execute a script during CE startup . In manual it says to put a script named startup.py into current CityEngine workspace. So I made a simple script that prints something in CE's console to check if it is working: startup.py: from scripting import * ce = CE() if __name__ == '__main__': print ("hello world from startup") but when I startup CE it doesn't print anything to console. However, when I execute it, it works perfectly so it shouldn't contain any errors. but it doesn't get executed automatically during startup. Am I missing something? also where exactly should this script be located by meaning "current CityEngine workspace" ? is it <workspace_root>/scripting.py <workspace_root>/<project>/scripting.py <workspace_root>/<project>/<scripts>/scripting.py I placed it on all loactions and it doesn't work. Any help appreciated. Mark

‎08-01-2017

Hi, I was working with 2016.1 in that time. Now, when 2017.0. (final, non-beta) came out, I tested it again and I believe I have same (or similiar) error: this error happens while exporting meshes of very large area into small tiles in .obj format. No more handles (SWT Error) occoured after around 10k exports (maybe this is the max limit of handles that OS provides to CE) The problem is that the entire area has about 90k tiles - so 90k exports for one layer. If we export several layers for one small tile, by multiplying this number, we can end up having about 500k exports in total. which means restarting it for 50times or more depending where the automatic process stopped working which can take weeks. Is there any way to solve this? maybe increase the number of handles for CE or to decrease handle usage? below is the error log (I changed the long path of our original python script location to C:\python_script.py for better readability): eclipse.buildId=unknown java.version=1.7.0_80 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=cs_CZ Command-line arguments: -os win32 -ws win32 -arch x86_64 -data @noDefault -data @noDefault -clean Error Mon Jul 31 20:22:43 CEST 2017 No more handles (PyException) - Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\python_script.py", line 327, in <module> export_meshes(return_coords(xx,yy,x,y),xx_yy,x_y,"mesh") File "C:\python_script.py", line 247, in export_meshes ce.export(ce.getObjectsFrom(ce.scene, ce.isGraphLayer), exportSettings) File "C:\Users\WORKER\.CityEngine\2017.0R.win32.win32.x86_64\jythonCache\jscripting\CE.py", line 434, in export PythonBridge.invoke3(None, 'CE', 'export', (objects), (settings), _jbool(interactive)) at org.python.pydev.jython.PythonBridge$MethodInfo.invoke(Unknown Source) at org.python.pydev.jython.PythonBridge.invoke(Unknown Source) at org.python.pydev.jython.PythonBridge.invoke3(Unknown Source) at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) org.python.pydev.jython.ScriptError: org.python.pydev.jython.ScriptError: No more handles at org.python.core.Py.JavaError(Py.java:516) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:188) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:373) at org.python.core.PyObject.__call__(PyObject.java:377) at jscripting.CE$py.export$24(C:\Users\WORKER\.CityEngine\2017.0R.win32.win32.x86_64\jythonCache\jscripting\CE.py:434) at jscripting.CE$py.call_function(C:\Users\WORKER\.CityEngine\2017.0R.win32.win32.x86_64\jythonCache\jscripting\CE.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:301) at org.python.core.PyBaseCode.call(PyBaseCode.java:157) at org.python.core.PyFunction.__call__(PyFunction.java:368) at org.python.core.PyMethod.__call__(PyMethod.java:151) at org.python.pycode._pyx1327.export_meshes$10(C:\python_script.py:255) at org.python.pycode._pyx1327.call_function(C:\python_script.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:184) at org.python.core.PyFunction.__call__(PyFunction.java:380) at org.python.pycode._pyx1327.f$0(C:\python_script.py:277) at org.python.pycode._pyx1327.call_function(C:\python_script.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1312) at org.python.core.Py.exec(Py.java:1356) at org.python.pycode._pyx1328.f$0(<string>:1) at org.python.pycode._pyx1328.call_function(<string>) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1312) at org.python.core.Py.exec(Py.java:1356) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:206) at org.python.pydev.jython.JythonPlugin.exec(Unknown Source) at org.python.pydev.jython.JProcess.run(Unknown Source) Caused by: org.python.pydev.jython.ScriptError: No more handles at org.python.pydev.jython.PythonBridge$MethodInfo.invoke(Unknown Source) at org.python.pydev.jython.PythonBridge.invoke(Unknown Source) at org.python.pydev.jython.PythonBridge.invoke3(Unknown Source) at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) ... 30 more Caused by: org.eclipse.swt.SWTError: No more handles at org.eclipse.swt.SWT.error(SWT.java:4387) at org.eclipse.swt.SWT.error(SWT.java:4276) at org.eclipse.swt.SWT.error(SWT.java:4247) at org.eclipse.swt.internal.ImageList.copyWithAlpha(ImageList.java:179) at org.eclipse.swt.internal.ImageList.set(ImageList.java:409) at org.eclipse.swt.internal.ImageList.add(ImageList.java:70) at org.eclipse.swt.widgets.Button._setImage(Button.java:126) at org.eclipse.swt.widgets.Button.setImage(Button.java:943) at org.corebounce.adapters.ObjectAdapterFactory.createPoint3DUI(Unknown Source) at org.corebounce.adapters.ObjectAdapterFactory.createInputField(Unknown Source) at org.corebounce.adapters.ObjectAdapterFactory.createInputFields(Unknown Source) at org.corebounce.inspectors.AdaptableInspector.createInputFields(Unknown Source) at org.corebounce.inspectors.AdaptableInspector.createPartControl(Unknown Source) at org.corebounce.inspectors.AbstractInspector.createPartControl(Unknown Source) at org.corebounce.inspectors.Inspector.createUIElements(Unknown Source) at org.corebounce.inspectors.Inspector.updateUI(Unknown Source) at org.corebounce.inspectors.Inspector.setInput(Unknown Source) at org.corebounce.inspectors.Inspector.setInput(Unknown Source) at com.procedural.ceui.wizards.ExportSettingsPage.createControl(Unknown Source) at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1246) at org.eclipse.jface.wizard.WizardDialog.access$4(WizardDialog.java:1238) at org.eclipse.jface.wizard.WizardDialog$8.run(WizardDialog.java:1227) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.wizard.WizardDialog.showPage(WizardDialog.java:1225) at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:915) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:428) at org.corebounce.ui.WizardUtilities$ScriptWizardDialog.buttonPressed(Unknown Source) at com.procedural.ceattribute.ScriptInterfaceExport.export(Unknown Source) at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.python.pydev.jython.PythonBridge$MethodInfo$1.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4144) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.corebounce.rcp.CBDisplay.readAndDispatch(Unknown Source) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.procedural.cityengine.release.Application.start(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

‎07-07-2017

Hi Thomas, thanks for reply. I don't think it is a Python limitation (but maybe I am wrong) because when I repeat this process by hand It also creates terrain with default resolution of 1024x1024. And I can manually increase the terrain to 4096x4096. And I was wondering if same could be done using some method in python. Well I understand using higher resolutions will slow down everything but we are already using tiled approach and can't lower tile size any more thus we need high resolution of 4096x4096 and looks like my machine can take this without slowing down everthing so is there any option/method in python that can do it? I thought everthing that can be done manually can also be done automatically using python. Maybe the functionality is there (because for example setAttributeLayerExtents is implemented and does similiar job) but somebody just forgot to document this particular feature

‎06-29-2017

Hello, I am able to create new terrain (CE calls it attribute layer) using: addAttributeLayer(self, name, texture=None, heightmap=None, useGeoRef=False) and I can also change the terrain dimensions and positions using: setAttributeLayerExtents(self, layer, extents) But I haven't found any information in documentation about how to set terrain resolution from default (1024x1024) to 4096x4096 using python script. Am I missing something or this feature isn't implemented yet? (so I have to do it manually) The reason why I need this is to automatically generate lots of CE projects (each will use it's own terrain tile + vector data) and automatically preprocess terrain (in full resolution) and doing this manually will take forever.. One incoplete workaround would be to: copy existing scene file containing only terrain layer with correctly set resolution and then change the other things (terrain coordinates and dimensions using: setAttributeLayerExtents ) but I also need to change elevation map and texture location and I'm not sure if this is possible either (haven't found information about it in documentation) thanks, Mark

‎06-09-2017

Hi Thomas, thanks for bug confirmation I tested your workaround and it solves this problem thank you very much any estimation on when it will be fixed? maybe in next release? Mark

‎06-09-2017

Hi Cheryl, thanks for answer but is it possible to extract these .cga attributes somehow and save them into the centerline shapefile? (for example using python) It will help me a lot with the traffic navigation - for example I specify in .cga rule attribute that a certain lane can only go straight (causing that this road segment will have texture with straight lines) and this information gets copied from .cga rule attribute also to object attribute somehow (maybe using python? - ce.setAttribute() ) from where it can be easily exported with lane shapefile so this line shapefile will contain an information in its shapefile attribute that this lane can only go straight so it can be used for traffic to behave accordingly is this possible?

‎06-06-2017

Hi, I have a simple graph network on which I applied default Street_Modern_Standard.cga rule: 1) When I export this network as a graph object (line/centerline shapefile): I lose attributes that are applied in cga rule: And only the Object Attributes and Segment parameters are written: 2) However, when I export this graph as a shape (area shapefile): all the cga rule attributes are written as shapefile attributes - but this exports roads footprints (areas) instead of lines (centerlines) which I want (for traffic navigation) as shown on the following image: Why the .cga rule attributes don't get written when I export the graph as graph object (1st option)? Is there any way how to export these .cga attributes as a line (centerline) using the 1st option or is it just a bug? thanks, Mark

‎06-06-2017

Hi, I'm having problem exporting terrain elevation as an image/heightmap (tif 32bit) - the exported image from cityengine is shifted by approx 25cm to the left and to the top compared to the original heightmap as shown on the picture below (screenshot from globalmapper) How to reproduce: Let's say I have: a 32bit tif (geotiff) crop of 1x1km terrain (heighmap) in WGS84 UTM 32N with nicely rounded bounds: (300 000,5 000 000 - 301 000,5 001 000) with 0.5m sample spacing (so that its resolution is 2000px x 2000px) I import this tif into cityengine an coordinates looks correct: (original terrain properties) then I changed terrain resolution from 1024x1024 to 2000x2000px and exported this terrain from CE to 32bit tif and load it alongside the original terrain an I get this difference (as shown on the first image) to double-check this problem, I also loaded the newly-exported terrain into cityengine and I can confirm that this terrain has different coordinates then the orignal one (ce-exported terrain properties) I can also visually confirm in CE that the original and exported terran don't match: Am I doing something wrong? or can anybody confirm that this is a bug? I checked the following things and none of them has an effect on this bug - the result is still exactly the same: shifted by 25cm: changing terrain resolution changing bit depth of tif during export terrain smooth/none toggle exporting non edited/edited terrain exporting edited/non edited terrain with elevation delta file for somebody it might look as if 25cm is not a big deal but for my workflow it is: I'm using tiled terrain in very-detailed city and I get a gap between the terrain boundaries and I need to export terrain from CE correctly because I'm doing heightmap adjustments to it I'm attaching the original and the exported terrain so that you can try to replicate this bug any help appreciated thanks, Mark

‎05-31-2017

Thanks all, that's bad news that this is a bug, I will have to recreate spatial envelope in python in CE then. And doing that I found another issue -> https://community.esri.com/message/690436-no-more-handles-swt-error-while-batch-processing-gdb-in-python do you have any estimation when it will be fixed? thanks, Mark

‎05-31-2017

Hello, I am processing large number of .gdb files the following way: load 500 .gdb objects in CE process these 500 objects export them as .gdb repeat during this process, CE briefly displays and closes import and export gdb dialog windows as it should but after few iterations (the above process is repeated ~500 times) It hangs up on one of these dialog windows and the script stops, UI freezes thus CE is irresponsible and I can't do anything with it other than close it. When I restart it, everything works as it should after I run the script again and it does another 500 iterations.. the problem that it displays is on the following screenshots - I am unable to post .logs of all the errors because UI is frozen at this state so I cannot open "save log" dialog window but I migh be able to make screenshots of all of them if it is necesarry: I was searching about this "no more handles SWT error" and found out that it's a common eclipse bug that has something to do with limited number of handles that OS provides to eclipse and when these handles run out an error occours or maybe it's a memory problem but I have 32GB and CE only uses 9GB Maybe this is not CE-related bug and more like Eclipse-related but I would like to ask if anybody has any idea how to fix it or workaround: Possible solutions that I can think of: increase number of handles that OS provides somehow (maybe edit something in CityEngine.ini) make CE cleanup itself after some iterations (~400) by using some python code (maybe run garbage collector etc..) force CE to close after some iterations (~400) and then start again and continue where it left - and repeat - this can work - I can restart CE but I don't know how to force it to run a specific script after startup any help is appreciated

Online Status	Offline
Date Last Visited	‎11-11-2020 02:25 AM

My Ideas

Latest Contributions by MarekDekys

Re: Engine crashes as I try and open a rule file that I made.

Re: Engine crashes as I try and open a rule file that I made.

backwards compatibility of CityEngine scenes with previous versions

Re: cityengine 2017 crashes on random shapes when generating geometry using complicated .cga rule - hs_err_pid - JVM EXCEPTION_ACCESS_VIOLATION

cityengine 2017 crashes on random shapes when generating geometry using complicated .cga rule - hs_err_pid - JVM EXCEPTION_ACCESS_VIOLATION

startup.py special script not working

Re: No more handles (SWT Error) while batch processing .gdb in python

Re: is it possible to set terrain (AttributeLayer) resolution using python? (from default 1024x1024 to 4096x4096)

is it possible to set terrain (AttributeLayer) resolution using python? (from default 1024x1024 to 4096x4096)

Re: exported terrain (elevation) from CE is shifted by 25cm compared to original (possible bug)

Re: export graph network as a centerline shapefile won't include cga attributes

export graph network as a centerline shapefile won't include cga attributes

exported terrain (elevation) from CE is shifted by 25cm compared to original (possible bug)

Re: [PYTHON] .gdb import - spatial envelope settings not working

No more handles (SWT Error) while batch processing .gdb in python

Re: [PYTHON] .gdb import - spatial envelope setti...

backwards compatibility of CityEngine scenes with ...