Way to create autogen library objects

[arno]

Hi all,

In this thread there is a discussion going on about the position accuracy of library objects made with scenProc.

http://www.fsdeveloper.com/forum/threads/point-placement-accuracy.429661/

Recently I was also thinking about changing the way autogen library objects are created. I would like to put these ideas here, so that you can give feedback if this sounds like a useful change to make.

At the moment autogen library objects can only be created from point features. If they are created from lines or polygons directly weird results happen. However in the AGN files, the library objects are not points but polygons. You have probably seen this when you draw library objects in Annotator.

So I am planning to change the CREATEAGNLIBOBJ step so that it works from polygons as well. That way you could also use building footprints for example and assign a library object to those polygons.

Since a lot of data about library objects are point feature, I will then add a new step that can convert these point features to polygons with a certain width and length.

Does this sound as a logic workflow for those of you who are currently creating autogen library objects with scenProc? Or do you prefer to have everything in one step that does both the conversion to polygon and the creating of the autogen library objects.

Let me know if there are other ideas or suggestions as well.

The proposed changes here only apply to the CREATEAGNLIBOBJ step, the CREATEXMLLIBOBJ step would not be changed. Since in the XML file library objects are points and not polygons.

 

[SprightlyOldMan]

Hi Arno,

I use CREATEAGNLIBOBJ to put the lights in the streets

I've noticed that vegetation polygons that have the lights inside, are removed.

I tried to use step SUBTRACTFEATURES to subtract lights from vegetation, but scenproc crashes (maybe because it can not subtract points, but only polygons?)

So I think it's really useful to transform the points in polygons

Hello
Chris

 

[arno]

Hi Chris,

Let me check what the subtract step does with points, but it indeed assumes polygons.

Interesting to hear that the library objects remove vegetation, I didn't know that. I know that vegetation does remove buildings when they overlap.

 

[Anto80]

Hi Chris ,
maybe I did not understand the problem, but I do not think that the lights rise up object
polygons of vegetation, you place an instance of lights inside the polygon as you see it is not deleted ....
Can you explain better?
Anto.

 

[Darren]

Hi Arno

The ability to place library objects from polygons will be very useful.

Since a lot of data about library objects are point feature, I will then add a new step that can convert these point features to polygons with a certain width and length.

I'm mostly thinking about building objects, so I'm not sure how useful this method of converting a point to a polygon would be though as there'd be no correct orientation of the building polygon/object, and essentially we'd get the same result already simply by assigning a certain agn class or object guid to the point feature, or we can transfer the point data attributes to the polygon data showing our building footprints.

What I think could be very useful is if we could provide sceneproc with a selection of agn class guids, listing objects of certain categories ( lets say all our generic building / housing object classes contained in the default.xml ) So the list we provide would restrict sceneproc to only using those classes of object. If a building polygon from our source data matches ( or very nearly matches ) the dimensions of an housing object class contained within our list (sizes taken from default.xml) then that agn class of library object is placed on the polygon and is orientated with it. Perhaps various filters could be employed such as IFINSIDE ect.

There would likely be a need to somehow prevent a double placement from our autogen1 ( normal agn buildings) scripting steps, so that the Autogen2 ( library object ) would take priority.

I suppose the list we provide is another configuration file. I picture something similar to the existing default.xml, except with an additional level in which we can group our chosen classes.

<Scenproc Classes>

        <CODE>filter name used by tool</CODE>

# containing all the below object clases #

    <CLASS>
      <NAME>Housing/Style 001/Row 90 degree</NAME>
      <GUID>3f156f760e9911e0b26b0030673010d8</GUID>
      <WIDTH>12</WIDTH>
      <DEPTH>12</DEPTH>
      <LIBRARYOBJECT>
        <NAME>Style 001 Row 90 degree</NAME>
        <GUID>0f2ef71d452dd7c7a8fdcb8cc8455866</GUID>
      </LIBRARYOBJECT>
    </CLASS>
    <CLASS>
      <NAME>Housing/Style 001/Row of 4</NAME>
      <GUID>3f1577640e9911e0b26b0030673010d8</GUID>
      <WIDTH>24</WIDTH>
      <DEPTH>8</DEPTH>
      <LIBRARYOBJECT>
        <NAME>Style 001 Row of 4</NAME>
        <GUID>abae9cd34198492deefa51827e0dd0bc</GUID>
      </LIBRARYOBJECT>
    </CLASS>
# ETC ETC

The list could be simplified to just use the class guids but I expect you see what I mean.

 

[MyPC8MyBrain]

very interesting concept
i think very tricky and complicated to execute

but that never stopped you before my friend

i admire you for venturing to those uncharted water

 

[arno]

Hi Darren,

I think your idea is inline with what I have in my mind. It would be nice if scenproc could place library objects that match the size of the polygon. I'm not sure yet how automatic this should be, in the filter you use in the configuration file the user could also do the selection of size and then assign a certain class. That way I don't think you need to select a subset from the default.xml first.

But I guess once I try to implement something we will find out what works best, based on the user feedback.

 

[Darren]

Hi Arno

Just as a thought...I think the concern if you made it so we were assigning a single agn class to a "size" of polygon is the danger of too much repetition. Houses in general fall into quite a narrow range of sizes, so I think it's quite important to allow multiple classes to be chosen ( whether that's from a list like the idea above or added in the *.spc file) but to lessen the possibility of too much repetition.
I know that we can have multiple Library objects within each class, so we could add all housing objects of the same size to a single agn class, and we can achieve a randomness that way. But in my case at least I've already built quite a large default.xml that has each individual housing object within it's own class. That way when I'm fine tuning a scene I'm able to place the exact building I want to. Like sometimes it's good to have an area where all the housing is the same style to simulate a housing estate. Which is where an IFINSIDE filter would be best used.
There's really some great possibilities once you start thinking about it isn't there. .

 

[arno]

Hi Darren,

Thanks for the extra details. I had indeed in mind that houses of the same size would be in one class. But I also understand your use case. Then it indeed makes sense to provide multiple classes to use.