|Anonymous | Login | Signup for a new account||2020-01-23 11:30 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007744||opensim||[REGION] OpenSim Core||public||2015-11-19 05:45||2015-11-24 01:18|
|Platform||x86_86||OS||Linux||OS Version||dev master|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0007744: Enhancements to 'load oar'|
|Description||Enhancements to 'load oar' command.|
Since the introduction of var regions there has been some functionality missing from the load oar command. Currently it is possible to load a standard 256x256m OAR file into a standard and a var-region and rotate and position it accordingly, however the parcel data is not processed properly (no rotation or repositioning). It is also not possible to take part of a var-region OAR and load it properly into a standard region.
This patch changes that. It provides full or partial loading of an OAR of any size (including the parcel data) and lets you rotate, crop and finally displace (position) the result into the target region. You can even take just a small section of an OAR, e.g. a 128x128m piece and place that into your destination region.
Most of the load oar parameters work exactly as they did before except --rotation-center no longer does anything as it confusing to visualise and is not actually needed when using the new parameters. All rotations now are done around the centre of the source region.
There are three additional parameters:
--bounding-origin and --bounding-size These are both Vector3 i.e. <x, y, z> and let you define which part of the source region is being used.
--debug This make the load oar command more chatty, providing info about loaded parcels and where objects will be placed.
The new 'load oar' parameters work in the following order and this is *important to remember*:
--rotation -359 to +359 degress. The source region is rotated by the desired amount anticlockwise in degrees. If not specified then no rotation takes place. (This may result in a intermediate source region that is up to nearly 50% bigger, depending on the rotation amount, but the coordinate system is maintained)
--bounding-origin <x, y, z>
--bounding-size <x, y, z> The (possibly rotated) source region is then cropped to a cube or rectangular cuboid defined by the coordinates given.
The resultant cuboid will then be placed at <0, 0, 0> in the destination region unless modified by:
--displacement <x, y, z> The rotated and cropped data is offset into the destination region by this amount.
Some things to note:
--rotation applies to all of the source region's data, that is terrain, parcels and objects (prims). Both terrain, and even more so, parcels do not rotate well using arbitary rotations like 45 degress as the edges will become jagged, but it's still supported.
The algorithm for rotating terrain data has changed. Previously the code iterated over the source data, placing rotated data into the destination. This of course often leaves holes in the destination that need filling using interpolation. The new code does the rotation by iterating over the destination array and filling it with data from the source, thus leaving no holes in the resulting data. For both parcel and terrain data, orthagonal rotations are special cased and are now more accurate.
The bounding cuboid is 3D for objects (i.e. only objects within the cuboid are used), but its 2D for terrain and parcels (only <x, y> is used).
The displacement is 3D for objects, and ALSO for terrain, i.e. terrain height is displaced up and down by the z component of the parameter. Parcel data is obviously still only 2D using <x, y> only.
--rotation-center parameter is still there, however it no longer does anything and just displays a warning when it is used. There is no need for this parameter as it is possible to achieve the same results with just the other parameters. It could be removed at next release - 0.9.1 ?
The remaining parameters work as they did before, even if I do think they are somewhat counter-intuitive in their meaning:
--merge Merge objects (rather than replace) into the destination region and disable parcel and terrain loading
--force-parcels Force parcels to load (and merge with existing) if using --merge
--force-terrain Force terrain to load (and merge with existing) if using --merge
Actually parcel and terrain data are always merged with any existing data on the destination region if the area being loaded is smaller than the region size. This means that for example, any claimed parcel areas from the source region that are being placed into the destination will claim the land even if it was previously claimed, or part claimed by existing parcel data. The existing parcel data will be modified to take the new claim area into account.
I am happy to maintain this code and fix any bugs to make sure it has no issues by the next release.
Please look at the attached diagrams that show the workflow and how easy it is to visualise and use.
|Tags||No tags attached.|
|Git Revision or version number||0fbb4f0067dd6ebda28ba27686686c09de473f83|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux64|
|Attached Files|| 0001-Changes-to-LandObject-and-ILandObject.patch [^] (22,117 bytes) 2015-11-19 05:45 [Show Content]
0002-Changes-to-TerrainChannel-and-ITerrainChannel.patch [^] (9,875 bytes) 2015-11-19 05:46 [Show Content]
0003-Changes-to-TerrainModule-and-ITerrainModule.patch [^] (3,702 bytes) 2015-11-19 05:46 [Show Content]
0004-Changes-to-load-oar-options-and-supporting-code.patch [^] (33,874 bytes) 2015-11-19 05:46 [Show Content]
standard-to-standard.png [^] (120,776 bytes) 2015-11-19 05:46
standard-to-var.png [^] (97,465 bytes) 2015-11-19 05:46
var-to-standard.png [^] (98,650 bytes) 2015-11-19 05:47
var-to-var.png [^] (91,825 bytes) 2015-11-19 05:47
0005-Fix-some-stupid-math-checks-on-Bounding.patch [^] (3,736 bytes) 2015-11-22 08:08 [Show Content]
edited on: 2015-11-20 03:58
Nice addition and I hope the patches pass scrutiny Jak.
I am sure this would follow, but just to say the obvious... when the changes are made the wiki ought to be updated with the extra parameters, and possibly your very helpful explanatory images also placed there. That tends to be the place I go to see the parameters and explanation, and I am sure others do as well, as getting help in the console can be tricky.
Mata Hari (reporter)
|Big thumbs up to this work...very handy!|
Jak Daniels (reporter)
|If the patches are accepted then I will write a new wiki page for the load oar command for opensim 0.9+ and cross link to and from the original load oar page.|
Garmin Kawaguichi (reporter)
|Great work(s) !|
|Just acknowledging this patch. I have a few issues with some the parameters, but also with the code. I speak with jak at IRC, and after that, (when im awake enough to do rotations) to start adding it|
|patchs applied, before they get outdated, any changes can be done anytime|
Jak Daniels (reporter)
Hi Ubit.... sorry for the late night getting the archiver unit tests to work again! I uploaded another small patch (0005) that corrects some stupid math and checking for the --bounding-origin and --bounding-size parameters. Bounding origin refers to coordinates in the source region and can be possibly negative. Bounding size must be between 0 and the destination region size.
|This is awesome. May I add a feature request, since you are improving OARs? Current OARs do not store Lightshare or Windlight settings, and they should. Could you perhaps add them, please? See Mantis 7205.|
Jak Daniels (reporter)
Hehe smxy... of course you can ask, but not sure if I have the time or the knowledge to do this... it would maybe mean creating a new OAR format version 0.9 ?
I'll have a bit of a code scan and see what it might entail.
Jak Daniels (reporter)
|The Wiki has been updated with a first stab at new documentation. The page @ http://opensimulator.org/wiki/Load_Oar [^] now has a link to a new page for 'load oar' in versions 0.9.0+|
edited on: 2015-11-23 13:11
Hi Jak... good to have the new features documented. But why have a separate page? Can you not merge the additions into the singie page and table as the format already allows for "since 0.9.0" annotation in one column. The diagrams can just be added as a section for "Since 0.9.0 in Pictures".
Changes, edits, and improvements otherwise will get added to one or the other and they will get out of sync.
Jak Daniels (reporter)
|Well, I guess I didn't want to make much change to the existing page until this new stuff has bedded in and been tested a bit. Many people will still be on 0.8.x releases right now so none of this applies to them yet. I think the time to merge them would be at 0.9.0 release, once it becomes a bit more 'locked down'?|
|Understood Jak. But now its actually commotted and in the core code base I think it just makes it easier to have it all in one place and not risk differential changes on the Wiki pages. Its really only a set of extra rows in ten main table and the pictorial section. OSGrid, for example, tends to follow dev master so a lot of people will have access to the new parameters soon. Anyway.. no problem whichever way you leave it for now as I am sure it can be coalesced when 0.9.0 is relaeased.|
|2015-11-19 05:45||Jak Daniels||New Issue|
|2015-11-19 05:45||Jak Daniels||File Added: 0001-Changes-to-LandObject-and-ILandObject.patch|
|2015-11-19 05:46||Jak Daniels||File Added: 0002-Changes-to-TerrainChannel-and-ITerrainChannel.patch|
|2015-11-19 05:46||Jak Daniels||File Added: 0003-Changes-to-TerrainModule-and-ITerrainModule.patch|
|2015-11-19 05:46||Jak Daniels||File Added: 0004-Changes-to-load-oar-options-and-supporting-code.patch|
|2015-11-19 05:46||Jak Daniels||File Added: standard-to-standard.png|
|2015-11-19 05:46||Jak Daniels||File Added: standard-to-var.png|
|2015-11-19 05:47||Jak Daniels||File Added: var-to-standard.png|
|2015-11-19 05:47||Jak Daniels||File Added: var-to-var.png|
|2015-11-19 05:48||Jak Daniels||Status||new => patch included|
|2015-11-20 03:58||aiaustin||Note Added: 0029580|
|2015-11-20 03:58||aiaustin||Note Edited: 0029580||View Revisions|
|2015-11-20 04:33||Mata Hari||Note Added: 0029582|
|2015-11-20 06:03||Jak Daniels||Note Added: 0029584|
|2015-11-21 05:03||Jak Daniels||Description Updated||View Revisions|
|2015-11-21 06:25||Garmin Kawaguichi||Note Added: 0029595|
|2015-11-21 14:26||UbitUmarov||Note Added: 0029597|
|2015-11-21 17:48||UbitUmarov||Note Added: 0029600|
|2015-11-22 08:08||Jak Daniels||File Added: 0005-Fix-some-stupid-math-checks-on-Bounding.patch|
|2015-11-22 08:12||Jak Daniels||Note Added: 0029602|
|2015-11-22 15:32||smxy||Note Added: 0029605|
|2015-11-23 10:58||Jak Daniels||Note Added: 0029609|
|2015-11-23 10:59||Jak Daniels||Note Added: 0029610|
|2015-11-23 13:09||aiaustin||Note Added: 0029611|
|2015-11-23 13:11||aiaustin||Note Edited: 0029611||View Revisions|
|2015-11-23 13:29||Jak Daniels||Note Added: 0029612|
|2015-11-24 01:18||aiaustin||Note Added: 0029622|
|Copyright © 2000 - 2012 MantisBT Group|