[11:01 AM PT] Ubit Umarov: (hi)
[11:01 AM PT] Andrew Hellershanks: Hello, everyone.
[11:01 AM PT] Andrew Hellershanks: Vincent, why was that a mistake
[11:02 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Well it's all full of.. not sure how to describe those people. They are living in another world based on the things that they say there
[11:02 AM PT] Vincent.Sylvester @hg.zetaworlds.com: From completely tone deaf to outright misinformation
[11:02 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Just awful all round
[11:03 AM PT] Joe Magarac: Oh. It used to be just annoying headhunters and consultants.
[11:03 AM PT] Andrew Hellershanks: There are still a lot of those. I ignore them.
[11:03 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's evolved to also include self-declared entrepreneurs talking about the hustle of selling toilet paper
[11:04 AM PT] Joe Magarac: Oh. Dropshippers.
[11:04 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Or corpo heads talking about workers like they are lower than the dirt they walk on
[11:04 AM PT] Ubit Umarov: dang forgot to buy toilet paper
[11:04 AM PT] Andrew Hellershanks: ubit, :)
[11:06 AM PT] Vincent.Sylvester @hg.zetaworlds.com: No code changes as far as I can see, but I made some in absence of that
[11:07 AM PT] Ubit Umarov: oh there was a fix to a typo on oars load
[11:07 AM PT] Ubit Umarov: was loadint pbr material 4 on top on 3
[11:08 AM PT] Ubit Umarov: ..off..
[11:08 AM PT] Ubit Umarov: ( c
[11:09 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I continued work on improving the TIFF loader. Adding a save-tile function based on true coordinates rather than the weird tile-based regionsize one. Also with a cutoff for only saving a part of a region for example only say one corner saved to a smaller file
[11:09 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Still have to do some debugging and hardening to make sure it's a bit more idiot proof
[11:09 AM PT] Ubit Umarov: what tile based?
[11:10 AM PT] Ubit Umarov: heights corresnpond to 1m grid points
[11:10 AM PT] Vincent.Sylvester @hg.zetaworlds.com: So when you do save-tile at the moment you give it two ints of number of tiles. A tile gets based on the region size, so a tile is 256, 512, 768 etc. tile number * regionsize
[11:10 AM PT] Vincent.Sylvester @hg.zetaworlds.com: This means if you wanted to place a 256 region in the center of a 512 image, you can't
[11:11 AM PT] Ubit Umarov: well you can
[11:11 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It builds a new coordinate system based on the position of the region you are saving with each coordinate being the size of the region itself
[11:11 AM PT] Ubit Umarov: just bc of resolution there mayne a little shit of 0.5m
[11:12 AM PT] Ubit Umarov: you are doing interpolation ?
[11:12 AM PT] Vincent.Sylvester @hg.zetaworlds.com: save-tile 3 3 999,999 would save a region of 256 size at coordinate 1000,1000 in the center of 768 file
[11:13 AM PT] Ubit Umarov: well save has no relation to load
[11:13 AM PT] Ubit Umarov: din't understand that
[11:13 AM PT] Ubit Umarov: if you wanted to do some interpolation that should be on load
[11:14 AM PT] Ubit Umarov: but terrain just has not precision to worry about that 0.5m
[11:14 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's not about half meters
[11:14 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's about that it you cannot save a 256 to a 512 file and center it in there
[11:15 AM PT] Vincent.Sylvester @hg.zetaworlds.com: You would have to save it. Then change the region size, load it to the center and then save it again
[11:15 AM PT] Ubit Umarov: that is not what you are suposed to do
[11:15 AM PT] Ubit Umarov: you save a 256m
[11:15 AM PT] Ubit Umarov: then you may load it into a 512..
[11:15 AM PT] Ubit Umarov: diferent logic
[11:16 AM PT] Ubit Umarov: those worries should be on load.. save should be at its current format
[11:16 AM PT] Ubit Umarov: wel that is how it is now
[11:17 AM PT] Ubit Umarov: a 256m can be loaded on a 512m
[11:17 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Sure you can load with displacement, but you cannot save with displacement. You also cannot save a larger region to a smaller file. Say you wanted split a 6x6 into 2x2, you can only do that on load which can be troublesome
[11:17 AM PT] Ubit Umarov: sure center will be a bit off.. but that is not relevant in most cases
[11:17 AM PT] Vincent.Sylvester @hg.zetaworlds.com: If you can load with displacement, save should be available too
[11:17 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's not a big deal to add, not sure what's got you so worked up about that
[11:18 AM PT] Ubit Umarov: think there is a limits box on save
[11:18 AM PT] Ubit Umarov: dont remember
[11:18 AM PT] Vincent.Sylvester @hg.zetaworlds.com: There are multiple roads to Rome, doesn't mean you should take the most difficult one
[11:19 AM PT] Ubit Umarov: hmm guess not
[11:19 AM PT] Jagga Meredith: (sings) "I'll take the high road..."
[11:19 AM PT] Ubit Umarov: save is abotu current region, not import into another
[11:20 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It was rather trivial to add. Nothing too crazy. The original save-tile confused me until I worked out how it does a new coordinate system. So TIFF should have access to all capabilities that terrain loading has
[11:22 AM PT] Ubit Umarov: coff coff coff
[11:22 AM PT] Ubit Umarov: :)
[11:23 AM PT] Joe Magarac: Who restarted the region?
[11:23 AM PT] Ubit Umarov: coff coff coff
[11:23 AM PT] Ubit Umarov: :)
[11:23 AM PT] Ubit Umarov: welcome back :)
[11:23 AM PT] Andrew Hellershanks: We are back.
[11:23 AM PT] Ubit Umarov: a few missing :)
[11:24 AM PT] Jagga Meredith: wha happen?
[11:24 AM PT] Ubit Umarov: sorry
[11:24 AM PT] Ubit Umarov: doing a c
[11:24 AM PT] Lyr Lobo waves
[11:24 AM PT] Andrew Hellershanks: :)
[11:24 AM PT] Lyr Lobo: Lost con or just resetting? *grins*
[11:24 AM PT] Lyr Lobo: hehe
[11:24 AM PT] Ubit Umarov: a cntl-c got in :)
[11:24 AM PT] Lyr Lobo: good times!
[11:24 AM PT] Lyr Lobo: was Gavin here?
[11:24 AM PT] Ubit Umarov: no
[11:25 AM PT] Lyr Lobo: Hello, everyone, sorry, was teaching and answering questions
[11:25 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Like how that also crashed my viewer
[11:25 AM PT] Ubit Umarov: as i was telling the oar load is the one that does displacements etc
[11:25 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Not just log out, ctd
[11:25 AM PT] Ubit Umarov: saves are on current format
[11:25 AM PT] Andrew Hellershanks: np. It didn't crash my viewer but told me I got logged out as the region went down.
[11:26 AM PT] Ubit Umarov: duhh now i killed the other region
[11:26 AM PT] Ubit Umarov: --bounding-origin will only place objects that after displacement and rotation fall within the bounding cube who's position starts at . Defaults to .
--bounding-size specifies the size of the bounding cube. The default is the size of the destination region and cannot be larger than this.
--displacement will add this value to the position of every object loaded.
[11:26 AM PT] Ubit Umarov: no idea why c
[11:26 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I am talking about heightmaps, not oar thing
[11:26 AM PT] Ubit Umarov: well at least did change the console to the other region :)
[11:27 AM PT] Lyr Lobo grins
[11:27 AM PT] Ubit Umarov: ofc limited import operations.. but there :;)
[11:27 AM PT] Andrew Hellershanks: Vincent, before we got booted you were saying: TIFF should have access to all capabilities that terrain loading has
[11:28 AM PT] Andrew Hellershanks: then I got logged out.
[11:28 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Yeah it didn't have the basic save-tile, so I did add that
[11:28 AM PT] Ubit Umarov: and remember it is terrain.. parcels limits etc
[11:29 AM PT] Vincent.Sylvester @hg.zetaworlds.com: In the process of doing that and finding how it works I decided to add a save-tile one that works based on actual meters, so you can save a part of a larger region to a smaller file if you wanted to
[11:29 AM PT] Ubit Umarov: changing heighmaps alone witll not align them with parcels
[11:29 AM PT] Ubit Umarov: etc
[11:29 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I am well aware
[11:30 AM PT] Ubit Umarov: wlel no idea what you mean abotu actual meters..
[11:30 AM PT] Ubit Umarov: height maps are at 1m grid points
[11:30 AM PT] Vincent.Sylvester @hg.zetaworlds.com: ...
[11:30 AM PT] Joe Magarac: While people are on this, I hae a new version of Sharpview out which gets the seams between regions right. https://animats.com/sharpview/releases/release-0.9.0.html
[11:31 AM PT] Ubit Umarov: ty joe
[11:31 AM PT] Joe Magarac: If you can find any adjacent regions that don't have proper seams, please let me know.
[11:31 AM PT] Ubit Umarov: also does the ll heights thing?
[11:31 AM PT] Joe Magarac: The "ll heights thing?"
[11:32 AM PT] Joe Magarac: Terraforming? Yes.
[11:32 AM PT] Ubit Umarov: i mean elevation ranges
[11:32 AM PT] Joe Magarac: You mean for textures?
[11:32 AM PT] Joe Magarac: It does that, but badly.
[11:32 AM PT] Joe Magarac: Don't have blending yet.
[11:32 AM PT] Ubit Umarov: well guess all to that badly :)
[11:33 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Again. terrain save-tile 3 3 999 999, saves a 256m x 256m region at grid coordinate 1000,1000 to a 768x768 pixel file right in the center. There is no way to save that same region to the center of a 512 pixel image, because it goes by tiles not meters. A tile is the size of a region, whatever that size, so when the region is 768 in size, so will be each tile. You would then still write 999 to center it, because it generates a whole new coordinate system that is based not on 256 regions, but 768
[11:34 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I found that rather annoying to not be able to set an offset directly in meters. The function that I added, save-tile-ext lets you put the size of the file in pixels/meters, the offset you want to start at and even how much of the region you want to save, in case you wanted to split a 512 region into 4 smaller ones
[11:35 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's more flexible for saving the heightmaps. Is there much point to it? Probably not, but it's a bit easier to accomplish than having to save and load to split them apart for example
[11:36 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I suspect the save-tile function originally didn't take into account var regions creating that slightly weird way of handling coordinates, which is counterintuitive
[11:36 AM PT] Ubit Umarov: no
[11:36 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I left the original function untouched, in case any other code needs it for whatever
[11:36 AM PT] Ubit Umarov: they just save current region
[11:37 AM PT] Ubit Umarov: global coords do not matter
[11:37 AM PT] Ubit Umarov: heigmaps have 0,0 at the normal left lower corner, the reference point for a region
[11:38 AM PT] Ubit Umarov: only issue you see is that to import you do need to know its size
[11:38 AM PT] Ubit Umarov: and to a little math
[11:39 AM PT] Ubit Umarov: if you just load, it will load with everyting also relative to reference corner
[11:39 AM PT] Ubit Umarov: ie all in regions local coords
[11:39 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Again, not the point of that
[11:39 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Try saving a normal 256 region to the center of a 512x512 pixel heightmap, without loading it on a temporary region
[11:40 AM PT] Ubit Umarov: cednter is not the reference point.. the left lower corner is
[11:41 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Oh god damnit. Picture the pinhead island yes, now what happens when you enlarge a 256 region after the pinhead has been created? It gets placed in the lower left corner right
[11:41 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Now say you wanted to have it back in the middle of the region like it usually is
[11:42 AM PT] Ubit Umarov: you add a displacement of 256m
[11:42 AM PT] Ubit Umarov: and is "middle" will be within 0.5m of region center
[11:43 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It would be 128 meters, but that's not the point, not half meters either
[11:43 AM PT] Vincent.Sylvester @hg.zetaworlds.com: It's about save-tile making its own coordinates and basing everything off the size of the region
[11:43 AM PT] Ubit Umarov: wel or 128 yeah
[11:43 AM PT] Ubit Umarov: thing is the the reference are the regions reference cornes..
[11:43 AM PT] Ubit Umarov: corners..
[11:44 AM PT] Ubit Umarov: everything is saved in region local coords, one could say
[11:45 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Like I said, save-tile 3 3 999 999, the first two ints are the tile numbers for height and width, that's 3 * 256, then it reads the global grid coord for the region, in this case 1000,1000 and by doing 999 you tell it to shift the region one spot diagonal, putting the 256 region in the middle of a 768x768 file. So if your original region is a pinhead island you now have a 768 with the pinhead at the middle of the region again
[11:45 AM PT] Vincent.Sylvester @hg.zetaworlds.com: The problem with this is that everything the function does is based on RegionSize, so the larger the region the larger the "tiles" are
[11:46 AM PT] Vincent.Sylvester @hg.zetaworlds.com: If you tell it to save 3 tiles of a 512 region you get a 1536 pixel file
[11:46 AM PT] Vincent.Sylvester @hg.zetaworlds.com: This also means that because it's all based on region size, you cannot save a 256 to a 512 file and still shift it to have the island in the middle again
[11:46 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Because the smallest tile is 256
[11:47 AM PT] Ubit Umarov: load with displacemnet of 128m will place it there
[11:48 AM PT] Ubit Umarov: ( then you need to fx the rest )
[11:48 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Yes, but then just to save the heightmap you'd need a temporary region to load it on and then save it again
[11:49 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Instead of all that and to make just a more flexible function I made this SaveFile(ITerrainChannel map, string filename, int fileWidth, int fileHeight, int startX, int startY, int stopX, int stopY, int offsetX, int offsetY)
[11:50 AM PT] Vincent.Sylvester @hg.zetaworlds.com: So you can specify a 512 pixel file and then save 256x256 of a 512 to it's center if you wanted to. start and stop are on the current map, offset on the file to save to
[11:50 AM PT] Ubit Umarov: btw some viewers may not like region sizes like 768 etc
[11:51 AM PT] Ubit Umarov: some my only work with 256, 512, 1024, 2048 ...
[11:51 AM PT] Ubit Umarov: 768 forces a textures resample
[11:51 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I remember that from months ago, fun bug that
[11:52 AM PT] Ubit Umarov: wel is is still a gpus restriction
[11:52 AM PT] Ubit Umarov: hey like things that are powers of 2
[11:52 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Which 768 technically is too, just different base ;)
[11:54 AM PT] Ubit Umarov: i actually did resize this region, if i remember
[11:54 AM PT] Ubit Umarov: it was 768 ??
[11:55 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Anyways, added that and implemented 16 bit grayscale as well. save-tile still checks bit depth and uses what's found so supports older 8 bit as well, but for TIFF at least it will save new files as 16 bit, which allows for terrain of 4096 in height... in case that's needed for something
[11:55 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Still have to clean that up a bit and test it to see how robust the loading is
[11:56 AM PT] Vincent.Sylvester @hg.zetaworlds.com: I had some failures when it cannot properly determine the bit depth from the metadata
[11:56 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Stepping through the file byte for byte essentially, cause gdi doesn't do 16 bit
[11:56 AM PT] Ubit Umarov: some code on that just assumes square regions
[11:57 AM PT] Ubit Umarov: we can't suport rectangular ones anyways
[11:57 AM PT] Vincent.Sylvester @hg.zetaworlds.com: Also still haven't found the cause for that weird first byte being wrong
[11:58 AM PT] Vincent.Sylvester @hg.zetaworlds.com: All in all though, it's coming along. Needs more testing and idiot proofing, but it's better than trying to work out how to convert r32
[11:59 AM PT] Vincent.Sylvester @hg.zetaworlds.com: TIFF 16 bit can be loaded in Gimp without any plugins, natively supports that type and can save to it as well, which means converting existing heightmaps to it and loading tall mountains is a whole lot easier
[11:59 AM PT] Ubit Umarov: so what is the vertical resolution of your tiff variant?
[12:00 PM PT] Vincent.Sylvester @hg.zetaworlds.com: 16 bit grayscale, so I should think it can handle at least 65k scales on that
[12:00 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I normalized it to 4096 total to make it easier to see
[12:00 PM PT] Ubit Umarov: how do you map that into height?
[12:01 PM PT] Ubit Umarov: and has negative heights?
[12:01 PM PT] Vincent.Sylvester @hg.zetaworlds.com: (ushort)((value - minHeight) * 65535 / (maxHeight - minHeight));
[12:01 PM PT] Joe Magarac: gotta go, next meeting.
[12:01 PM PT] Vincent.Sylvester @hg.zetaworlds.com: It's shifted 256 meters up so terrain at -100 lower limit should not be handled
[12:02 PM PT] Vincent.Sylvester @hg.zetaworlds.com: Else it'll just throw an exception lol
[12:02 PM PT] Vincent.Sylvester @hg.zetaworlds.com: int terrainheight = ((int)map[x, y]) 256;
//Console.Write(terrainheight.ToString() " ");
ushort pixelValue = Normalize(terrainheight);
writer.Write(pixelValue);
[12:02 PM PT] Ubit Umarov: well all that variance was what forced us to just use r32
[12:03 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I could shift it farther up or Math.Clamp
[12:04 PM PT] Ubit Umarov: err so on that yr resoltuon is 1m
[12:04 PM PT] Ubit Umarov: resolution...
[12:05 PM PT] Vincent.Sylvester @hg.zetaworlds.com: From what I can tell it save and load don't cause any different looking terrain
[12:06 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I did see some function to retrieve floats from the heightmaps
[12:07 PM PT] Vincent.Sylvester @hg.zetaworlds.com: From what I could tell the save functions in the other loads are all saving as ints
[12:07 PM PT] Ubit Umarov: our internal heightmpas are floats now
[12:07 PM PT] Ubit Umarov: ..maps
[12:07 PM PT] Ubit Umarov: no other format does cover all kind of terrains ppl made
[12:08 PM PT] Ubit Umarov: ( ofc neither do the saves in image like formats )
[12:09 PM PT] Vincent.Sylvester @hg.zetaworlds.com: Normalize should scale the terrain across 65k and then turn it into ints that should give quite a bit precision with a max height of 4k
[12:10 PM PT] Vincent.Sylvester @hg.zetaworlds.com: About 16 steps per meter
[12:10 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I saved a terrain and then loaded it from file. I didn't see it shift anywhere really
[12:11 PM PT] Vincent.Sylvester @hg.zetaworlds.com: About what 8 centimeter resolution in height, think that's good enough?
[12:12 PM PT] Ubit Umarov: possible
[12:13 PM PT] Ubit Umarov: the ll compression makes that confusing
[12:13 PM PT] Vincent.Sylvester @hg.zetaworlds.com: Oh yeah I have not handled file compression in the 16 bit loader, so that will not load unless it's an uncompressed TIFF file
[12:14 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I did explore png as well, but the forced compression on that is making the save load by bytes a lot more difficult and memory intensive
[12:14 PM PT] Ubit Umarov: nahh it is ll specific compression fo rlludp
[12:15 PM PT] Ubit Umarov: terrain is sent in blocks of 16x16m
[12:15 PM PT] Ubit Umarov: compressed with a crude imitation of jpeg
[12:15 PM PT] Vincent.Sylvester @hg.zetaworlds.com: Terrain patches, yeah those are fun for various reasons
[12:16 PM PT] Vincent.Sylvester @hg.zetaworlds.com: If you don't send them the viewer tries to render them anyways and in the process gets really slow
[12:16 PM PT] Ubit Umarov: but terrain can have mm of resolution..
[12:17 PM PT] Ubit Umarov: again.. we just gave up and used r32 to cover all cases..
[12:17 PM PT] Vincent.Sylvester @hg.zetaworlds.com: That full 32bit for grayscale?
[12:17 PM PT] Ubit Umarov: well we do not read those as image :)
[12:18 PM PT] Ubit Umarov: but yeah something like that
[12:18 PM PT] Vincent.Sylvester @hg.zetaworlds.com: You can create 32bit floating point images with grayscale in Gimp. I can try to see if TIFF supports those
[12:19 PM PT] Vincent.Sylvester @hg.zetaworlds.com: Suppose it is a bit of a trade off. You can have higher precision in r32, but a b**** to edit them or less precise TIFF you can actually view and work with
[12:19 PM PT] Vincent.Sylvester @hg.zetaworlds.com: More than 8 centimeter precision is cutting grass with scissors level lol
[12:20 PM PT] Ubit Umarov: yeah a assumed waste
[12:20 PM PT] Ubit Umarov: well we used to store then as doubles internally :P
[12:20 PM PT] Ubit Umarov: that was a big waste :)
[12:21 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I'll take a look at possible bit depths for TIFF just to see, but hopefully just going to 16 bit for TIFF will be a lot less hassle than r32 or having terrain cut off at 256 meters :)
[12:21 PM PT] Ubit Umarov: well rl calls
[12:21 PM PT] Ubit Umarov: any other opensim issue?
[12:22 PM PT] Vincent.Sylvester @hg.zetaworlds.com: If System.Drawing really dies and we move to something else that might support that out the box anyways
[12:22 PM PT] Vincent.Sylvester @hg.zetaworlds.com: I know ImageSharp does
[12:22 PM PT] Ubit Umarov: ok cya here or there :)
[12:23 PM PT] Ubit Umarov: have fun
[12:23 PM PT] Lyr Lobo: thank you!
[12:23 PM PT] Lyr Lobo: Have a great day, must dash!
[12:23 PM PT] Andrew Hellershanks: Any other last minute items before we wrap it up?
[12:23 PM PT] Andrew Hellershanks: Thank you for coming. See you again next week.
