Macrocosm Draegonne

I was thinking about this recently, its a monumental task that will require refactoring of the servers, they must have some mind numbing data on that idea already but can you imagine the challenge? wowza! ? I said on one of your threads what I figured might be a way to do it. Basically turning any grouping of SIM's into a single logical MMO style worldspace, abstracting only all thats related to avatar travel into it, whilst relieving the SIM's of that duty. Mainland continents can be huge though, so they might need zones within the bigger zone? I dunno. Then for continuous travel between continents... maybe an interface that pops up when you hit the SIM edge or designated TP spot giving you a choice where to pop-over too with a loading tp screen transition. Or better yet, put them all on an actual globe, with fully navigable sea, and above 4k air travel space between them all, lmao!

One more Again, not a demand, just an interest. Web-Prims - I tinkered already & they're cool! Perhaps they could be expanded? Increase performance & allow some additional use-case types? Say we only want a js midi synthesizer, and/or text to voice reader, audio tracks, etcetera, basically script and sound only, no need for an interactive screen-space or browser functionality. Could we have a lighter version of webprim that is script and/or Sound focused only? Id love to offload processing to my other servers, or simply use such efficient code it can process right in the Data: with a few externally loaded scripts. Or load in sounds externally so not to drag the SL servers as much? Maybe that data: block allowance could be increased too? Perhaps we could also have web-prims with no networking, this type could be for making HUDS, styling a new additional type of Notecard with a WYSIWYG, using actual fonts & html design/effects in things in game. html is really capable of a lot, even without its networking functionalities, and a great many people know basic usage for simple stuff. We would need a lot of restrictions on this area of course, but these "lighter" web-prims would be useful, and maybe even performance enhancing, since chromium can spawn new system threads, whilst having a light footprint, if used correctly. I would imagine the most expensive to the system are the interactive browser windows, but as you can see we could have several different types which dont use that functionality at all, or very minimally.

I am curious about a few things, none are demands, but all are interesting to me. Additional shaders, not only for visual appeal, but also for how much potential texture reduction & increased visual diversity that could offer. Linden Tree's? I read a few bits about them here and there, and it seems they did all sorts of cool things, but were retired, can we get some of those plant shaders and features added back for creators to apply to flora? Linden Water - I am most curious about updating the water shader with some minor enhancements, mainly fading out the specular/normal effect as you near close and right up to the waters edge meeting land(but not other things), this would give the appearance of a more smooth land/water edge transition at all angles. Generally though, anything to enhance and improve the water would be welcome. Maybe even allow us to set a prim as LL water, so pools/lakes dont have to do so much work for a lessor visual effect. Texture Atlases with internal tileable quadrants? Would be nice if we could use them, Blender & most 3d apps can build them for an object or scene. Occlusion Tools - Prims that completely hide all textures/mesh placed inside its cube space from rendering/downloading to anyone outside of it. For occluding things like a lot of games do, another variety (less SL specific) is occlusion planes, im sure you already know what those are. A way to hide all avatar mesh that has not yet loaded its attachment point, even if they're just a jelly doughnut or a cloud for a few min thats fine. ? Please tell us more about the Cloud enhancements, and what interesting things you're cooking up with the considerably expanded tool-set you've got more access to now, im so curious!

Yeah thats what I assumed about it being mostly server side, however there was a nice little feature added to Firestorm recently that keeps you from flying off sideways at least. Its quite nice that. It seems the challenge is to have a macro level landspace, or at least groups of them, joining all actually connected SIMs to a logical zone, some would just be a few, mainland has several big continents. This way you're always traversing the one thing, like a lot of MMO's do, but then you'd also need to still have consideration for the way SL functions, and protect SIM's from too much influx. Perhaps the larger worldspace (used only for the limited data needed to allow avatar travel) could likewise relieve individual servers of that task and burden? Giving a double whammy boost to performance, and eliminating the perception of SIM crossings completely, except for windlight changes of course. I am honestly not that familiar with the infrastructure yet, but I I can imagine that SIM crossings are quite a considerable technological feat. Edit: One of the huge benefits further embracing cloud infrastructure, SL can more easily separate logical components into their own servers, even on an as needed basis. It will be helpful to solve SIM crossings, instancing game experiences, caching, and who knows what else? Most of my drupal websites now have 7 servers each, as well as three branches dev/test/live, and dev can be multi-branched, plus it all load balances, and auto-scales as needed. The cloud is amazeballs!

Firestorm is awesome, definitely my go-too when im building and most often my general play, I also use blackdragon when im doing photoshoots and such, which is another great viewer. I dont mean to pry too much, so feel free not to answer of course, but what compels you to compile your own? Working out some new feature potentials or just for your own enjoyment?

It totally didn't occur to me that we were allowed to compile our own viewer, so long as we follow the rules. I must prevent myself from jumping down that rabbit hole anytime soon, I would love to tinker with that very much!

It's also worth noting that its likely SL is already doing the automated atlas thing when it bakes terrain textures (including tileability), id guess it does it for performance reasons and ability to revert back to previous set. Im not entirely certain of this of course, i cant just look at the server code lmao. But it seems very plausible. I can only upload four 1024 images to the interface which would make a 2048 atlas, unless they downsample to 1024, I dunno, theres no way to click the terrain and inspect.

Oh too funny, looks like Sansar supports texture atlases, for the performance benefits, imagine that? So LL knows they have value, but of course implementation and system setup mean different things for different games, but generally speaking texture atlases are a good practice, when they're used correctly.

ooh love them, saw them live a few times, good stuff! No, im genuinely asking if that is applicable? If you have a nice mesh object like a table, where they baked all the materials to one texture, you cant simply decide to change the wood grain on the legs, you'd have to recreate the image and put new pixels in the uv areas you want to change, or else change the mesh. Thats how it is now for mesh, they're not often modifiable, and even if they are you still are bound by the UV map in the mesh, and it completely dictates how you texture must be, else it will be borked. Any object with an atlas is an object with one diffuse, there is no interface to change areas of a UV map, only one texture slot to adjust, we have to change the whole image to change the texture on the object. So, there is no way to change just one section of the atlas, unless its an automated system of some type. I never said you make no sense, but that particular point is IMO not applicable. And we've already all agree'd the bake system in its current form is not ideal for automating it, it would be some potential future enhancement, but nothing more. Atlases though I feel are important in the mix, which is why I have attempted to see if there are any potential tools they could give creators to utilize them smartly.

How is that applicable ? You cannot change the individual texture spots, you'd have to replace the whole atlas, just like texturing any other object which bakes multiple materials to uv areas in the texture space, you cant just swap one little part out, the whole image must be replaced, & uv maps cannot be changed without altering/reimporting the mesh. i wouldn't expect an atlas to do that really, except maybe in one particular use case, if object level atlases were ever automated, to combine all textures into an atlas, but thats really a bleeding edge case of a wild feature, not really anything too important to demand or anything.

The only person being offensive here is you, with name calling and judgments. Check your privilege at the door, it means nothing to me, I treat everyone fairly, I do not care who they are. This post, which you conveniently ignored, is what is actually being discussed, review that and see where your response is considerably out of context. I appreciate the that the bake system has limitations and maybe is not a good fit for making an atlas, THATS WHY I ASKED the question to begin with... But we can easily export them from Blender, and many other apps. So an object has that added level of performance optimization which is not in any way a bad thing, or causing any more additional textures to be loaded than were going to already. The only possible overhead is handling tiled texture quadrants which couldn't possibly be that intensive.

That... right there, its very definition of a straw man argument. I have never claimed texture calls were the biggest problem. Only that they're one factor in performance of a scene, one that a texture atlas actually improves performance on. Straw man #2 I never made such claims, you seem to enjoy them because it gives you something to lash out at. AKA definition of a straw man argument. No additional pixels are being loaded, not even one... straw man #3 Yes, it would have too right? You've built that man of straw for a purpose! You still have not addressed the actual topic at hand, but who knows, perhaps the straw man has become real to you? Or its purely an accidental fabrication?

It was an idea yea, I was curious if parts of the same bake system could be used to make a user-friendly way of combining the textures on upload into an atlas. But, honestly thats certainly not anything of great need, only a cool feature. My biggest desire was more in the direction of being able to use texture atlases at all, for the benefit of reducing texture calls, and being able to tile internal quadrants. There are other ways atlases could be auto-generated server side when the setup decided it was prudent, but that is really another topic, one that really got some people fired up! lol I am not scared to discuss anything, I am impartial, and expect nothing other than to share my opinion.

well, in the context of the avatar bakes, they're semi-permanent, because they can be changed all the time, its a beast of a tech challenge actually quite impressive. I have made similar things on servers in the past for websites, compositing layers into one final output using imagemagick and custom scritpts with a UI for setting up what they want on their own, but whats going on here is far far more advanced and challenging. What I am most interested in with the context of this post though are the one time atlases made with the creation of the mesh that would go with an object, or set of objects.

Im just waiting for someone to explain why reducing texture calls is a bad thing, I am tenacious, I will not give up unless there is a clear logical, or even emotionally satisfying, reason to do so.

lol, I do enjoy a good candid bantor, it is fun indeed! I take no offense whatsoever, and I hope the feeling is mutual. The bake angle on this is only the question I posed, if that were even a viable potential. I am not married to the idea, but it seemed worth discussing. The concept of a texture Atlas is fairly solid though! Sure there are many cases its not useful, but there are also those in which they are actually performance enhancing.

In case anyone is wondering what she's arguing against, if that can even be said? Seems the straw man has her all mixed up at this point. Anyway, here is a quick illustration of what I am actually talking about. A texture atlas is for all the textures in an object, when it even makes sense to combine them. You will not be loading textures you do not need to load, you will ONLY BE LOADING THE SAME TEXTURES YOU MUST LOAD NOW without a texture atlas. Depending on the context of the object and scene of objects an atlas may or may not be useful. Its situational, but it IS a performance enhancer. Below is one simple example of a four faced object, which would then allow up to four textures, one for each material face. You can then also add up to 8 more Normal maps, and up to 8 more specular maps too, bringing the total textures to as many as 24 per object. Even this example of using half available texture allowance would be 12 textures (including materials normal/spec). With an atlas system that could be reduced to one texture call for the object, and that atlas can be used on other similar objects too, further reducing need to load textures. Note: Yes, larger textures will really reduce this issue im highlighting, but it will be cut short in that we cannot tile quadrants within that texturespace, unless they go all the way across the texture, and even then thats only in one direction, left/right or up/down. That is where a Texture Atlas comes in, because you can do just that, tile internal quadrants. Note 2: Im mostly speaking to large objects here, ones that use tiled textures to cover more area with less textures. Those cannot simply be put lower quality in a uv map, you need to tile in all four directions, without an atlas those must be textures by themselves.

lol, well, the vomit inducing bit is more related to having a crap potato computer that cannot do at least 100fps, VR needs higher frame rate than regular screens, or you get dizzy. I do not have the gear myself, but I have tested it, and it is actually intensely immersive and fun. My philosophy has always been to wait it out, as prices come down, tech improves, safety improves. Did they claim Sansar was a replacement? I never knew that, I always saw it presented as a completely different game, and one that would likely NEVER be as robust and featured as SL is, because its a different kind of game geared towards micro VR experiences. They did lift the idea of Experiences from SL, which is smart, because that area is in need of more work here at the SL side, so it gave Sansar a unique thing it can do SL cannot do at that performance level, yet. Did they really say that though? I didnt see them claim Sansar would replace SL, that would be a bit of a shock since SL is so much more featured and capable in almost every area. You keep talking about pixel usage, yes, its a given to do that, many do not, I dont care to discuss that, I am talking about textures that are efficiently laid out, and more precisely, the issue of downloading potentially 8 files to texture one object, a larger texture could reduce that to 1 or two, especially if we can ever get tiling of quadrants within a larger image. Less texture calls is good thing, even if the file size stays the same You do love a straw man argument dont you? Trouble is that it makes literally no sense in the context of the convo, while it may be funny and cheeky, its not logic based, or even plausible here. You pose some rather wild accusations and condemnations based on assumptions you just conjure out the deep recesses of your ass. lmao, you think less texture calls is a bad thing? ok, carry on with that idea, I certainly have no desire to take your binky away.

Yeah, im so amazed by the coming features I hardly care to wait longer for that bit, if it happens at all. Though... I suspect they will not have too much difficulty with star-fields, constellations, shooting stars, anything they think is a good fit and wont bog the system, its OpenGL the sky's not even the limit! We can do all the things!? In all the years I've been playing SL, I have never been more excited than right now, there are so many goodies in the works, and its all making so much progress too.

There is a video on youtube about it, and they also posted some posts on their blog about it, I did not bookmark, but basically what I said above is what you do. Say you have a floor, you then duplicate it, in edit mode you can just drop it right there, if you're in object mode you drop it, then join the two with the join command, this makes it so its one when you export dae. There might even be other ways, but thats how I do it. Putting them into the same .dae will save you on li im thinking too. Once its in world, click around on the surface and drop your textures into them, in blender if you baked an AO/shadow/detail layer to go on the top layer, make sure its on the top layer of your surface in question, and the repeating base texture is set on the back plane. It can be a bit figidity selecting the layers, but there are scripting ways to deal with that, though, its really only needed if you have more than two layers, even a third layer will vex you as you try to click and get the right layers lol.

I hear ya, but I would guess those are all known factors to them too. Being in the drivers seat they can navigate any such issues, its the cost of being in business, its the work of it, one that every organization may face from time to time, success is in the persistence, fail forward, or never win at all. Most people sit on the sidelines and ***** because they're scared to loose, or too timid to buck up and make a success where most others would give up at the first road block, or mere perception of a road block, if they're attempting anything at all. What was able to be done in Sansar will be a benefit here on the SL side too, the disconnected dev allowed them to explore a lot of different things without legacy concerns. I would guess anything good that would fit will make its way back here, most of which will be server & cloud tech, but maybe other stuff too. VR is just getting started, and Sansar is not only VR, ive never used VR over there, but I will do this winter. I see Sansar as basically skyboxes with no actual world/realm. That can be useful for specific things which would be better served as individuated experiences. I certainly will be building some things over there too, but like I said before, the whole concept of SL is far more exciting, a lot more of a technical challenge, and potentially a whole lot more capable than Sansar is even meant to be. Im sure LL has made more than enough $ over there to cover the expense and propel it forward, and they will certainly make more if they keep working at it. The lead time to make SL high enough frame rate for VR to be viable here is considerable... and is in the works, but as you can see in that time Sansar has been able to develop into a full platform, whilst SL is still overcoming legacy issues, and embarking on ever more improvements and enhancements. The CEO said as much as that in the recent town hall. Sansar has its place for what it is, and none of that is a failure AFAIC, and yes I do know what I am talking about, having successfully started/launched/expanded a very successful multi million dollar corp (now in its 10th year with well over 100 employees and mega expansions coming), as well as being part in developing quite a good collection of others. Im not claiming to be some genius but I do know what I know. None of the concerns you named are anything a real business person would be too bothered about, all of those are factors to be considered and planned around, and overcome in moments that is required. If you've ever worked on a project, which I assume you have, you would know there are pitfalls and schedule issues, and it takes time, and many iterations before something comes into full function. Especially when related to tech. Oh and I cannot even waste one second on whether or not people take me seriously, like I said before, managing other peoples perceptions is pointless, fruitless, and impossible. Whatever is in that mind of theirs is what they will perceive. Yea it does get brought out in meetings often, but I am speaking of an interview he did on that SL talk show. He was speaking to the technical aspect, and explained how and why its totally possible and will happen eventually. How the 1024 limit is a relic that will soon enough be put to rest. I say throw it in the museum with the duck-walking, sculpties, and particle bling. There is no amount of UV mapping that will increase texture space beyond doing a proper UV job. What most people seem to end up doing instead is just adding more textures, which is a hit on performance. When we can have larger textures there will be far less actual individual textures per object potentially, at least for creators that are optimization oriented; which I am, I am obsessed with the topic, not in the sense of being over optimized, but every bit thats optimized is another bit that can be used for additional style and overall appeal.

no need to make them separate DAE. Simply duplicate the mesh you want the additional texture on and drop it in the same spot, being duplicated makes it the 2nd in the stack layer order and it will be on top of the previous mesh that was copied, join the two together as one object (but still two split sections), then in world you can click around on the surface and sometimes you'll select the back, others the front layer (zooming in close helps) or you can use scripts to control the texture layers. From there you can place your textures on to the object. Its nice actually because you can change the repeating textures in the lower layer but your shadows always stay nice and on top.

lol, like I said, you did not agree. How could it possibly fail before its even fully launched? Its in creator beta still right? Meaning, get the creators (and potential creators) over there and in on the development. Once its launched fully to the public and has a good year or so run then we will know if its a success or not. I dont see any reason why it shouldn't succeed so long as they keep working on it and perfecting it. Personally Im more excited by the core concept of what SL is and can be than Sansar, but thats not because Sansar isnt nice, its just a totally different thing with some similarities. Who knows what the future holds for Sansar? Its difficult to say until it goes fully to the public, it would be quite a surprise for it to fail before even starting though. No, he was explaining how the old systems cannot handle but so many textures, where the 64 bit viewer can do more and perform better, but that few actually even use the 32 bit viewers anymore. The next section he discussed increasing texture sizes, because someone asked. He was casual about it, and made it clear its totally possible because of legacy issues that are not so much of an issue as they once were. What is incorrect about adding two more textures, we have one, now there are three to make materials work, its using the same uv maps and layering system as the diffuse, the same bake servers, the same interfaces, etc. What makes you think they cannot figure it out? Why are you so certain there will be no materials support? No doubt the whole thing is a great technical challenge, but its not a great leap from the diffuse to the normal, or diffuse to spec, layer order takes prescience in whats visible in the final render, including any alpha opacities, the goal is having them look as close to the original disparate textures as possible, unless opacity layering causes some new blending effects, but even then they just choose a way and thats how it will be, and we will build around the way it needs. You're projecting, I take zero offense of course, but its sad to think you've got all that going on in that head of yours. You may want to be a bit easier on yourself there.?

I named two actually. One was the concept of reducing land prices and using a more fair-use-tax on sales as a revenue stream to keep the lab going strong. It was smart for Sansar and its smart here too, I was very pleased when that was announced. Two: There were developers that came from Sansar to LL, I can only imagine the context, but I assume its a good thing and related to cross-talk and cross-pollination of tech ideas. The oversized textures is a relic of 32 bit systems, at least thats how Oz explained it, the 1024 limit is all about those poor souls on half dead 32bit potatoes. As he was explaining more and highlighting that the texture size limit will be increased. You jump back to a previous comment about a wild idea for a potential automated system as if it were the issue at hand, that was one sentence in one post, you're going to have to get used to my wild ideas and literally zero *****s given about sharing them, or how people perceive them. :P Also I never have any problems with being wrong either, so I really dont care what I say or share, and im never upset to learn a new thing in the process either. I was at the meeting, they spoke in fairly constructive intonations I deciphered as meaning. AKA they plainly said (after it was asked) materials are going to happen, after... the actual difficult development is done. All they are is another texture for f's sake lol, a normal, and specular, combo-baking in the same way as the diffuse will. Maybe they're just enjoying the added suspense with you all? Bahh! Advanced materials, who needs those? ? I have read a few things here in the forums, though not much on BOM other than recent posts, I was gone for quite a few months while I was moving across town and building out my new office. I am sure people are keeping up the pressure, and I am glad for it, we must have that to keep LL's feet to the fire, im sure they appreciate it too, at least when its constructive, and supportive. EDIT: One more edit just to be clear, I like your attitude and banter usually, please dont mistake my teasing, disagreements, or return rhetoric as dislike or hatefulness, I love people who can keep sharing their opinion in the head winds.

Are you a native English speaker? Or do you just read more into things than are actually there? Just because you carry on with name calling and derogatory terms directed at me does not mean I must get down in that funky energy with you. I call everyone dear, and I could give a ***** what they imagine that to mean, its impossible to manage other peoples perceptions. I named them, you didnt agree, not the same thing... reality does not conform to your desire to feel superior. Yes, and the ones where it would be useful are interesting to me. You've already imparted your thoughts on areas in which texture atlases are, in your opinion, not useful. Really? I was at creator meetings over a year ago where they assured us that under no circumstance were materials off the table, only that it was secondary to the primary, more difficult, time consuming aspects of the system were worked out. Combining textures that should be combined is not backwards, the thing surely isnt released and fully featured yet, but the concept itself is not fatally flawed, its beta, in development. I may not know every single aspect, but your making me LOL seeing you trying to argue that reducing texture calls is a bad thing. 5+ textures on the head, 5+ textures on the body just for skin effects is silly, and thats saying their body/head combo is even that efficient, ive seen worse yet. Combining them is less textures, no matter how many less, it is less. Beta caveats aside, the idea is brilliant, and when its done im sure it will be useful. Most of the heads I have can have can have 17+ textures (not including their material layers), all of which can be baked into the main diffuse with BOM. Leaving one extra layer for onion skin would potentially increase that, but the creator can keep that in mind when making their new BOM enabled HUDS, that extra layer can be used for things other than actual skin related effects. Same for the body, there are tons of zones a texture can go, reducing those to less is a good thing there too, leaving the one onion layer for flexible use, but also preventing BOM type skin related applications on the onion layer here as well would be smart.