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
