Friendlyskies AoI Forum

utrrrongeeb · October 11, 2009, 5:02 am

Testing a script I'd written last year, I suspected that the raytracer converts scripted objects to meshes, even if the script produces non-mesh primitives.
This particular script generates thousands of spheres. The renderer takes much time at the "Processing scene" point. However, if an equivalent number of spheres are made the the Array tool, the renderer flies through "Processing scene" without delay.

I was thinking of converting my object script to a tool script, but for some reason tool scripts takes many times longer to execute than the near-instant object script -- enough so that it's unusable. The Array tool behaves similarly to the tool script -- perhaps they're being slowed down by the LayoutWindow?

Any thoughts on how to get a win-win solution here?

SlugFiller · October 11, 2009, 11:16 am

Scripted objects are object collections. The raytracer handles object collections by iterating over the objects, and adding each to the raytraced scene. In other words, spheres added by the script are still handled as regular spheres.

Only a distortion track would cause it to be converted to a mesh.

If there is a delay, it is probably cause by the script itself. The slow run-time of the tool script suggests the same. It could be that the apparent "near-instant" run time of the object script is simply caused by the fact that the object script is only ran when it is created, loaded, or rendered. When you are simply previewing it, it is not constantly being ran.

utrrrongeeb · October 12, 2009, 5:27 am

SlugFiller wrote:
Scripted objects are object collections. The raytracer handles object collections by iterating over the objects, and adding each to the raytraced scene. In other words, spheres added by the script are still handled as regular spheres.

Hmm... I hadn't know that, but it makes sense....

SlugFiller wrote:
If there is a delay, it is probably cause by the script itself. The slow run-time of the tool script suggests the same.

Interestingly, the tool script runs far more slowly than the object script, despite that the tool script should only have to be run once.

If you don't mind having to kill an unresponsive javaw, try this tool script:

Code:

/*
Generates a large number of spheres in a cube-shape.
Set dimcount to the number of spheres on an edge.
The total number of spheres will be dimcount^3.
*/
int dimcount = 10;// 10 is usually safe
double size = 0.05;
double gap = 0.2;

ObjectInfo parent = null;
ObjectInfo noi = null;
Sphere sp = new Sphere(size,size,size);
for (int ix = 0; ix < dimcount; ix++) {
    for (int iy = 0; iy < dimcount; iy++) {
        for (int iz = 0; iz < dimcount; iz++) {
            noi = new ObjectInfo(sp,new CoordinateSystem(new Vec3((ix*gap-(gap*dimcount/2)),(iy*gap-(gap*dimcount/2)),(iz*gap-(gap*dimcount/2))), 0, 0, 0),"cube "+ix+","+iy+","+iz);
            if (parent == null) {
                parent = noi;
                window.addObject(parent,window.scene.getNumObjects(),null);
            } else {
                parent.addChild(noi,parent.children.length);
                window.addObject(noi,null);
            }
        }
    }
}
window.rebuildItemList();

Setting dimcount beyond about 12 can take an unreasonable amount of time, while a comparable object script can produce nearly 50,000 spheres without freezing.

Last edited by utrrrongeeb (October 12, 2009, 5:29 am)

SlugFiller · October 12, 2009, 3:01 pm

I think the real slowdown is in the last line:

Code:

window.rebuildItemList();

This line first generates the tree, then for each object it runs over the entire tree causing O(n^2) behavior.
As far as I can tell, there's no reason to call it, since "window.addObject" already takes care of things.
Additionally, "addChild" also makes things O(n^2). You should forgo having all of the objects children of each other, and instead add them all directly to the scene. That way, you can also forgo the expensive use of specified indices:

Code:

            noi = new ObjectInfo(sp,new CoordinateSystem(new Vec3((ix*gap-(gap*dimcount/2)),(iy*gap-(gap*dimcount/2)),(iz*gap-(gap*dimcount/2))), 0, 0, 0),"cube "+ix+","+iy+","+iz);
            window.addObject(noi,null);

Now I looked to see if the raytracer might experience similar difficulties. It uses synchronized ArrayLists, which work just like Vectors (why not just use Vectors?), so it is definitely O(n). No issue there. So I can't think why parsing the script may be an issue. The issue may, instead, be of the raytracing process itself - it is computationally intensive, after all, and a bunch of spheres could certainly be expected to cause some slowdown.

At any rate, if you want "rebuildItemList" and "addChild" to be fast, you'll have to talk to Peter. It's just how the code is built.

Friendlyskies AoI Forum

Announcement

#1 October 11, 2009, 5:02 am

Massive scene script inefficiencies

#2 October 11, 2009, 11:16 am

Re: Massive scene script inefficiencies

#3 October 12, 2009, 5:27 am

Re: Massive scene script inefficiencies

SlugFiller wrote:

SlugFiller wrote:

Code:

#4 October 12, 2009, 3:01 pm

Re: Massive scene script inefficiencies

Code:

Code:

Board footer