Object generation utility

  • lenidcamper

    Hello Stu, can you tell please, what is wrong with my code?

    It only generates the standard name objects "pier_2_5", but does not trigger on the individual pier:width


  • 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.

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

    Edited 4 times, last by lenidcamper: pps ().

  • Thank you Stu for your commens.

    Yes silly from me, not to use #GE# ...

    But as this criteria triggers OK for me, the main problem in fact is, that it does not trigger the conditions:

    expression="($pier:width == '150')"

    etc.


    These are my OSM data:


    I now tried 0150, but that did not help either:

    together with

    expression="($pier:width == '0150')"


    The LOG looks OK so far, but finally, only the type

    <[string8][geometry][..\objects\Piers\Pier_Wood_1_6\pier_wood_1_6]>

    is exported.


  • 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?

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • 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!!!


    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

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

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

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • Published release 0.7.2 of ObjectGen


    Some bug fixes plus intersection exclusion functionality.


    Without exclusion collisions are unavoidable.





    With exclusion

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • I wish moving traffic was that easy!!!


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

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10