That is the plan. When working, you can create a 512x512 region, edit it with the usual editing tools or load a terrain image from a file, and the terrain will be saved and restored when the region is restarted and saved and restored in OAR files.
There is a bug in today's version of 'varregion' that doesn't seem to properly save the whole region but I'll fix that today. -- mb On Tue, Nov 5, 2013 at 8:41 AM, Todd Adams <[email protected]> wrote: > so, if you modify the terrain, it will remain persistant? > > > On Tue, Nov 5, 2013 at 11:28 AM, Mister Blue <[email protected]>wrote: > >> I haven't completed the terrain loaders (there are a bunch of them for >> all the different image types). In the video, I don't stretch the terrain >> which is why the one region is a little raised from the rest[1]. >> >> I was hoping to make it so loading terrain images will adapt to the size >> of the region. Thus, you could have a 1024x1024 BMP image and use that as >> the heightmap for a 1024x1024 region. There is some complications with the >> offsetting features of the heightmap readers that will take a little >> fiddling. >> >> -- mb >> >> [1] It read the terrain data from the database as the original 256x256 >> and had to fill the rest of the 1024x1024 with something and, at the >> moment, that something is 21. The terrain information will be stored as >> 1024x1024 when the terrain info is saved and will be restored as such. I've >> co-opted the terrain 'revision' database field to denote the format of the >> database terrain heightmap blob. >> >> >> On Tue, Nov 5, 2013 at 6:18 AM, Todd Adams <[email protected]> wrote: >> >>> Question - is the terrain image now 512x512, 1024x1024 etc, or do you >>> still use a 256x256 terrain and just stretch it? >>> >>> >>> On Tue, Nov 5, 2013 at 9:04 AM, Mister Blue >>> <[email protected]>wrote: >>> >>>> A varregion is just one large region and not several regular regions >>>> glued together as for megaregions. varregions will save and restore terrain >>>> and prim position as if the region is just that large. >>>> >>>> As to why square, that is a known feature/limitation of the viewer >>>> code. The varregion code in OpenSimulator enfoces the squareness so users >>>> are not surprised. >>>> >>>> -- mb >>>> >>>> >>>> On Tue, Nov 5, 2013 at 4:56 AM, James Stallings II < >>>> [email protected]> wrote: >>>> >>>>> I'll be giving this a shot later today MisterBlue :) >>>>> >>>>> Thanks for this work! >>>>> >>>>> >>>>> Cheers >>>>> James/Hiro >>>>> >>>>> >>>>> >>>>> On Tue, Nov 5, 2013 at 6:02 AM, R.Gunther <[email protected]> wrote: >>>>> >>>>>> "Additionally, the large regions must be square." >>>>>> >>>>>> Hmm. whats then the difference at the end between mega region and >>>>>> variable region ? >>>>>> Except that megaregions still misisng support for things. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2013-11-05 08:08, Mister Blue wrote: >>>>>> >>>>>> An update on 'varregion' development: >>>>>> >>>>>> As some of you know, I've taken on the task of porting the Aurora >>>>>> variable region feature into OpenSimulator. >>>>>> >>>>>> The port uses the Aurora's protocol extensions so the existing >>>>>> Firestorm and Singularity Aurora Support will work for OpenSimulator. The >>>>>> larger regions size will be restricted to multiples of 256 meters and >>>>>> adjacent regions (the ability to have other regions spacially next to >>>>>> larger regions) will not be implemented. Additionally, the large regions >>>>>> must be square. >>>>>> >>>>>> All of the code is in the 'varregion' branch of the OpenSimulator >>>>>> git repository. The implementation is downward compatible in that all >>>>>> existing 256x256 region functionality will continue to work. Things like >>>>>> storing terrain information in the database only change if a larger >>>>>> region >>>>>> size is specified. >>>>>> >>>>>> The basic functionality is working and here is a video of me >>>>>> driving around a 1024x1024 sized region. The raised area in one corner of >>>>>> the large region is the standard 256x256 region size. The viewer is the >>>>>> latest Singularity alpha but even it limits draw distance to 1024. >>>>>> >>>>>> http://youtu.be/aCDOnfb_n_M >>>>>> >>>>>> There is still testing and debugging to be done before this goes >>>>>> mainstream, but larger regions are around the corner. >>>>>> >>>>>> If you are feeling adventurous, I need people who are willing to >>>>>> run existing 256x256 regions with the 'varregion' branch code. If I can >>>>>> verify that existing, legacy region configurations are not broken by the >>>>>> new code, the 'varregion' branch can be merged into the 'master' branch. >>>>>> If >>>>>> you are up for testing, send me a line. >>>>>> >>>>>> -- mb >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Opensim-dev mailing >>>>>> [email protected]https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> <http://www.avast.com/> >>>>>> >>>>>> This email is free from viruses and malware because avast! >>>>>> Antivirus<http://www.avast.com/>protection is active. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Opensim-dev mailing list >>>>>> [email protected] >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> =================================== >>>>> http://osgrid.org/ >>>>> http://simhost.com >>>>> http://twitter.com/jstallings2 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> [email protected] >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> -- >>> >>> Todd Adams >>> [email protected] >>> 937-304-4951 >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > > Todd Adams > [email protected] > 937-304-4951 > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
