Posts by lenidcamper

I wish moving traffic was that easy!!!

By "collision" I meant more than one vehicle occupying the same coordinates

Published release 0.7.2 of ObjectGen

Some bug fixes plus intersection exclusion functionality.

Without exclusion collisions are unavoidable.

With exclusion

Yes, what looks like a valid expression is always returning false.

I will have to see if I can reproduce the problem.

sorry I did not scroll down in the include.

Based on the log, the string compare (without leading zero) should have exported 2 different models.

But it is actually exporting <[string8][geometry][..\objects\Piers\Pier_Wood_1_6\pier_wood_1_6]> ???

I don't see where that could possibly come from based on the included config.

"1_6" does not appear anywhere in the config!!!

As I mentioned in the postscript to a previous post, the expression engine did not internally resolve data types of

variables and all variables defaulted to string. So it was doing a string compare for all numeric variables in expressions.

I am testing a fix that loads int or float variables as required.

In the pier example what is the expression in the model map?

Hi Thomas

A number of issues here

At first I thought

"Of course, you are not using the operator alias #GE# for >="

The expression engine provides the alias/escape strings for operators to avoid special characters in XML. However >= will actually evaluate correctly.

"<=" will give a syntax error. for consistency it is probably better to always use the alias strings

The (...) construct is intended to define precedence in the expression. The ($pier:width) defeats my variable preload algorithm.

I am parsing the expression into tokens on spaces to pick out variable names to preload before tag data is loaded. This avoids a "variable not defined" exception from the expression engine and allows the sparse tag negation functionality added in 0.7.1

Use $pier:width #GE# '10' or ($pier:width #GE# '10')

That lead me to the core problem. It appears there is a bug in the XSharper engine with comparison of left justified numeric values.

($height #LE# '90') will evaluate true for height tag value '100'

but

($height #LE# ' 90') will evaluate to false

I need to look under the hood of the XSharper engine to see if there is any way to fix this or find a workaround.

/Stu

PS

what tag data are you comparing?

zero padding will work.

'090' will evaluate correctly compared with '100'

where '90' will not.

If you have added these tags using leading zero pad

PPS

turns out XSharper variables were defaulting to string type.

need to detect tag datatype and force a cast to int or float as the variable is set.

Attached is a parking density example.

Only one shared model map is required.

parking_density.xml.txt

Quote from TomSimMuc

I have a request for parking density:

Thomas

I have looked at the parking density issue. Adding a computed parameter is possible but is a can of worms I would rather not open right now.

Particularly since there is a work around for this issue.

All it requires is separate configurations for the few (3? 5??) different parking densities.

Each configuration would have a selectionCondition expression with the appropriate parking_density value and randomInteger upperLimit.

Using sharedModelMaps there will only be a dozen lines for each configuration.

If there is a scenario that cannot be solved without numeric tag operations I can look at the issue again.

/Stu

Quote from TomSimMuc

could it already work?

There is currently no way to specify arithmetic operations on tags. The XSharper expression engine has that capability. I only exposed what was needed for boolean selection expressions.

I need to think about a generic way to expose this.

Quote from Jet-Pack

Under Windows \ or / might both work

I had not placed any attention towards platform independence. I can update examples and documentation to forward slash and lower case.

Updated ObjectGen with v0.7.1

Minor release

• Allow output file name as optional command line argument
• Add support for negation of sparse tags eg ($highway == 'primary') #AND# ($tunnel #NEQ# 'yes')

Quote from TomSimMuc

command to set the name of the file(s) to save?

I overlooked the embedded name issue with the TOC.

Since I use tile based cultivation with a folder for each tile, renaming was never an issue for me.

No problem to add the output file name argument.

It is possible with the current release of ObectGen to place a building object at the "midpoint" of a building footprint.

As with the scenProc FLENGTH the wayLength derived tag could be used to distinguish residential vs commercial.

The random tag could be used to mix model types.

Currently the objects would have random orientation.

It is difficult to derive a meaningful orientation for an arbitrary polygon. If the way has 5 nodes it is a square or rectangle and an axis of orientation could be derived. But few houses are simple rectangles (particularly in NA housing developments).

Quote from TomSimMuc

all necessary direction and randomizing features I ever wished.

thanks Thomas

I am sure you will think of something

Uploaded version v0.7 of ObjectGen

The main feature is XREF library support.

There are some schema changes to support this.

There is a standalone xmlConvert utility to migrate locally modified configuration files to the current schema.

See the readme and User Guide

I have seen examples of TSC files with enumerated [elements] and with [0]

I assumed the scenery loader needs to merge [element] entries from multiple TSC files into an internal list anyway so enumeration does not seem

to be particularly relevant. Since it works without enumeration I did not bother to add it.

As for the [autoheight_override] I am unclear on the interpretation. I forget where I copied the original snippet for the template but it did have [-1]

Models I have placed at zero elevation in Sketchup seem to render at grade level with it set to [-1] (or [10] ) so I left it at [-1]

For an object model with larger area, if there is a slight slope in the elevation data one edge may be floating or depressed.

I had to extend the pylon piers well below grade to avoid floating pylon legs on steeper grades

If [autoheight_override] is set to [0] only XREF objects will render (no user defined objects).

As with the element index the autoheight_override did not seem broken so I did not fix it.

Changing the default values is easy if there is a "correct" answer.

Adding an optional model configuration element is more work so I would need to see good justification for the change.

The models I have converted worked fine with a zero elevation in Sketchup and autoheight_override of -1

Stu

Quote from TomSimMuc

can you introduce an empty parking lot factor?

You don't need dummy map entries.

If you set the default model name to empty string and set the upperLimit on the random tag to be appropriately larger than the number of (real) entries in the model map, when there is no match in the model map the empty default model is exported.

In v0.7 the [tmsimulator_scenery_object][element] will no longer be exported if the model name is blank (to avoid the "..\..\..\..\objects\.tmb' not found"messages in the TM.log)

I had assumed that the default model was fail safe and would always exist , but that is no longer the case.

Quote from kenventions

Maybe when Jeff is farther along with vehicle animation

the preview of Aerofly Life is very interesting.

It may make ObjectGen traffic redundant.
No indication yet of how the traffic is defined or how easy that will be for large areas.

The same issues of multiple lanes and intersections need to be addressed.

Quote from kenventions

any creative solution for the car traffic at intersections?

Variable density at intersections is pretty far down the list.

There are more significant issues to deal with for crossing ways.

Even in the motorway scenario there is the problem that there is no easy way to detect that the crossing way is actually an overpass (flyover) and no vehicles should be placed at the crossover unless it is a rail underpass then it is ok. A crossing line algorithm would be pretty slow for a node set in the thousands.

At street intersections there is the problem of 2 lanes becoming 4 lanes without any change in the OSM way.

Or a 4 way stop intersection with multiple turning lanes tagged (and drawn) as a roundabout.

That is on top of the general way misalignment to highway center line issue.

There are limits to the realism of vehicle cultivation without extreme efforts on the processing side and a lot of tweaking of the OSM data

Quote from TomSimMuc

no one is always parking strictly to the front line

The spacing can be randomized slightly.

The offset could be a min max. Even for highway traffic the vehicles don't always stay centered in the lanes.

Then of course we need a orientationMode of Random to give a mix of nose-in / node-out.

Although in NA 95% of people park nose-in unless they can pull through.

Or convert from orientationMode enum to orientationSense value

100 => 100% Forward

50 => 50/50 mix

0 => 0% Forward ( ie 100% Reverse)

I added the FORrotationOffSet attribute in version 0.6 to correct what I assumed would be an infrequent problem of models defined in a non standard frame of reference.

It turns out there is some unanticipated functionality available with this attribute. It gives a way to tackle the parking lot scenario.

There were no appropriate OSM features already defined for parking lots, so I added ways down the center lines of the parking rows and tagged them parking="double_row"

With appropriate tweaking of spacing and offsets and using a FORrotationOffset of 90 I got what I think is a reasonable representation of a parking lot.

A slightly sparse random mapping (without buses and trucks) leaves some empty spaces.

PS

Will update next release to not export nodes with blank model names to support sparse mapping scenario

but avoiding "..\..\..\..\objects\.tmb' not found)" messages in tm.log

Released version 0.6.0 ObjectGen

Main feature is the virtualObjects capability.

This will export objects along a way at a fixed or random spacing with a configurable offset from the path of the way.

The obvious example is randomly spaced traffic along a highway. Oh, it must be construction season because we have construction markers on the lane divider line.

This scene was generated with the example.xml in the release package. The scenario is expecting Rodeo's new car library to be available in the objects folder.

As usual check out the readme and UserGuide for details of the new features.

cheers

Stu

PS

The construction markers are not just a joke. They give a useful indication of how well the ways align with the center line of the highway feature.

In the screen shot above they align quite well, but in other sections they deviate by several meters and the traffic wanders off the road. You may need to tweak the highway feature alignment in your OSM editor.

PPS

wait till you see Rodeo's cars at night.