will there be a binary?
On Tue, Nov 5, 2013 at 12:02 PM, Mister Blue <[email protected]>wrote: > 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 > -- Todd Adams [email protected] 937-304-4951
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
