Inconsistent and non-updating occlusion query results (CE 2017.0)

660
4
Jump to solution
07-11-2017 05:58 AM
LR
by
Regular Contributor

I'm having trouble generating consistent query results. They're mostly correct where there's clear overlapping, but at the edges of the target object I get random results that are nowhere near it. Also, sometimes a querying object that's very far away from the target triggers as well. I've tried classic touches(), touches with label as well as overlaps(), with and without label - these all lead to the same result (screenshots 00-03).

Furthermore, I can only do one initial query. When I change the size of the target of the query and regenerate the checking objects, they still behave like I didn't change the target at all (04). However, when I save the scene and reopen it, the query is performed against the changed target - but any changes to it are again ignored. The random results described above repeat as well (05-06).

Lastly, what's the reasoning behind this decision (from the changelog): shapes of a scenario are not considered by queries of default shapes?

0 Kudos
1 Solution

Accepted Solutions
CherylLau
Esri Regular Contributor

After some investigation, we found that this is a bug.  The bug is due to imprecision at large scales.  For example, if you scale down the stuff in the scene so that the buildings are more like real-world building sizes, then the accuracy will be better, and it won't behave like it does in the screenshots.

Thanks for sharing your project and helping us find this bug.

View solution in original post

0 Kudos
4 Replies
ThomasFuchs
Esri Regular Contributor

Thank you for your questions.

For the 2017.0 release of CityEngine the capabilities of Context Queries have been extended. One new feature is the possibility to check a labeled geometry. The CGA Changelog gives a complete overview of all those new features and enhancements.

The some effects you are describing might be caused by a performance setting in the CityEngine preferences for the  Procedural Runtime . Edit > Preferences > General > Procedural Runtime > Occlusion and Context

The default value for Neighborhood distance for inter-occlusion is 1.0.

This means that occlusion testing with the target only happens with checking objects whose initial shapes are within 1m.

Please try if changing the setting is enhancing the accuracy.

If this doesn't help, please provide more information about the initial shapes you are using.

CherylLau
Esri Regular Contributor

There are actually many possible issues that could be happening besides the one that Thomas mentioned.  There could also be a bug.  In order to help find out what's going on, would it be possible to post your scene and rules?

How is the dome shape being enlarged in 04?

In the help doc:

Context (and Occlusion) Queries 

  • Shapes of a scenario are not considered by queries of default shapes.

-> This is because we do not want the default set to be influenced by any other scenario.  For example, we do not want scenario 1 to influence the default shapes.  If this were the case, then, when you look at scenario 2, you would see default shapes that were influenced by scenario 1, and this is not good.  We want each scenario to be independent of the other scenarios, and we want the default shapes to be the same in each scenario.  The default objects should not change depending on what scenario you are looking at.

LR
by
Regular Contributor

A little update: the second problem fixed itself somehow. Changing the shape is being recognized by the buildings without having to reopen the scene. I can't quite tell how it fixed itself, not even power cycling the machine changed anything before.

The first problem persists, however - at least when I update the seed and generate. See attached project. I left some screenshots in the image folder as well. The initial ground shapes were made with CE (rectangle, then subdivided). Everything else is rule-driven. Options were left at default.

CLau-esristaff wrote:

-> This is because we do not want the default set to be influenced by any other scenario.  For example, we do not want scenario 1 to influence the default shapes.  If this were the case, then, when you look at scenario 2, you would see default shapes that were influenced by scenario 1, and this is not good.  We want each scenario to be independent of the other scenarios, and we want the default shapes to be the same in each scenario.  The default objects should not change depending on what scenario you are looking at.

Understandable, but this prevents scenarios that show in what ways different setups would impact the default shapes. I guess they'd have to be instanced for every scenario in that case, though.

0 Kudos
CherylLau
Esri Regular Contributor

After some investigation, we found that this is a bug.  The bug is due to imprecision at large scales.  For example, if you scale down the stuff in the scene so that the buildings are more like real-world building sizes, then the accuracy will be better, and it won't behave like it does in the screenshots.

Thanks for sharing your project and helping us find this bug.

0 Kudos