Lots of NextGen questions as usual, plus some improvements coming to CurrentGen.

First of all, apologies for not getting this summary out sooner. We have been swamped the last few weeks and editing these summaries can be time consuming.

Right up top: Let's talk about October. Our October Q&A was scheduled for the 13th, but Adam had to travel internationally and wasn't going to be able to make it, so we've rescheduled to October 20th at 9am Eastern (1pm UTC). This is our euro-friendly time slot, and we hope you can make it!

Now let's see what got asked this (last) month!

⏹ What are your thoughts about Meshy and similar AI content generation services?
⏺ Tricky subject, there is no real answer we can give that won't age badly. Noboody necessarily thinks AI-driven content is that great right now, but we've seen glimmers of it becoming part of workflows and doing impressive things. There's a spectrum between prompting things into existence and curating an AI-assisted workflow. We shouldn't arbitrarily place marks down on that spectrum, in 2 years time placing those gates will seem really foolish.

The second angle on that is with economics. A lot of the concern/fear is around it potentially making hand-built content unviable. That's a tricky question to answer too. We can't give a firm answer on this right now, it needs a lot more thought, and this will likely evolve over time with the technology. We lean towards tagging content as AI, but where is the line if something is partially AI built? Is 30% too much? 50%? 70%? Is it fine if it is AI-scripted but not AI-drawn? Where do we draw this line? There's not an easy yes/no answer right now. The answer may be that the filter itself needs to be a spectrum. It's not a simple yes/no though, we're not banning it, but it needs careful thought.

The other side of the coin is that it is getting better. There's a possiblity for AI-created content in the future to allow for some interesting experiences. Adam used to build gigantic environments to play with, and when you do that you kind of run into Bethesda-syndrome in that you get a lot of broad-stroke content and small details end up the same all over. AI has the potential to make procedurally generating things at scale much more interesting by leveraging these tools. Again, complicated, but probably tagging of some kind. Is it "AI-created" if the AI arranged the composition of the content (rocks, trees, buildings, etc) that a human hand-made? There's a lot of nuance to this topic. It's divisive, but there's not a black/white answer that makes sense. We want to avoid mass-produced junk content, but we don't want to gate AI-assisted high quality content out entirely either.

⏹ Can we use AI agents in NextGen?
⏺ Yes! In fact, we've been testing that because some of our enterprise stuff relies on it. So NextGen has to support it to be viable. So yes, it will be there.

⏹ Can we integrate our own LLMs/DLLs for AI?
⏺ There is a recent change that includes support for WebSockets. This means you can send bidirectional messages back and forth between backend services, including LLMs, and have them tied directly into scripting. DLLs into the viewer... leaning heavily towards "probably not." This has huge remote-code-execution exploit potential. We really don't want to encourage people shipping outside plugins, in large part because trust is very important for users. There is some potential with sandboxing, but we really would just rather keep improving our scripting engine to have safe versions of the capabilities you need to do what you want to do. NextGen's scripting API has so much more than CurrentGen has, which reduces the need for augmenting the viewer code with DLL plugins.

⏹ Can an existing Sinespace account/business be transferred or gifted to another perosn?
⏺ Yes, we have done it in the past. Starts with a support ticket of course, and then we have a process that we need to follow for legal reasons. We have to clear some things you've signed on your account, like the creator EULA, as the new owner needs to re-sign it. That's for a whole account transfer. If we need to transfer individual items, that's more complicated, but can be done if there's a good reason for it. In any event, a support ticket is definitely where you want to go for any account related issues like that. (https://sine.space/support)

⏹ What is the region concurrency for NextGen going to be like?
⏺ Good question! We've given this a lot of thought. If we implement the full design we've mapped out, it gets crazy big. The networking protocol we've built allows for grouping/aggregation as well as CDNs. WE can use that same technology to deliver significant quantities of avatars to users. It's built in to the protocol. At least in theory, that means a very large number of users possible at the networking level, potentially hundreds of thousands. The problem is that even the best computer would burst into flames trying to do that, so the NextGen system has some substantial fallback capability so that the avatars can fall back to increasingly lower quality avatars to support larger numbers as needed. Our goal is to not go backwards on anything, some people here have seen us do as many as 650 real users, and 1000 bot users, on the current gen. We definitely wouldn't want to support less than that in nextgen if CurrentGen can already do it. At some point there is always the question of "Is the experience improved by having more users in one place?" Once you get beyond a certain number of people/avatars in a single place, they just turn into noise. You're never going to directly interact with 1000 people at once, much less ten thousand or a hundred thousand in the same space, so there's always the question of "is there a better way to curate this experience than simply making the number go up."

⏹ What are the min NextGen specs?
⏺ Min specs will be going down from CurrentGen, for sure. A dodgy laptop will suffice, to be honest. I've got a very cheap chromebook, and a super cheap Lenovo that was like $100 new, the lowest I could find. These are what we're testing against as min specs. There's a lot of overhead cut out here. RAM needs are very low, but graphics is a more nuanced problem. It really depends, you can dial it down to as low of quality as you're willing to tolerate, down to simple shapes and colors if needed to make it run on a given hardware. We're targeting getting the web browser version done first, which forces us to consider and handle wild limitations at the very low end with WebGL, and then scaling up quality from there... the sky is the limit. It really is just about how low of quality you're willing to tolerate.

⏹ What voice system is going to be used in NextGen?
⏺ WebRTC based system, of course. We just implemented the voice provider we're using now in CurrentGen in NextGen using our new plugin architecture, and other voice options can be easily slotted in. We know from experience it probably will be necessary at some point, as CurrentGen has had somewhere around 13 different voice providers over the years.

⏹ Will all this optimization mean that NextGen will look worse than CurrentGen high-spec machines?
⏺ No, absolutely not. If you have a powerful desktop then it should be even nicer looking than CurrentGen does. Web browser versions are necessarily lower quality due to browser limitations, but the full app can go whole hog. This of course is as much about the specific content as it is about the technology, though. You can already make extremely simple low-poly avatars and regions in CurrentGen Sinespace if you want, or up to full AAA quality content. Our goal with NextGen optimization is to make the really high end content run better on lower end machines than it does on CurrentGen, not to limit the maximum level of content that can be made.

Let's move to talking about some general status updates:

Adam was sick for the early part of September, but is mostly better now. While sick, though, he has been his fleet of AI agents run amok on CurrentGen and NextGen at the same time.

CurrentGen improvements include the ongoing rearchitecting of our entire content system (as discussed some in August). Once that big centerpiece element is done, we can start shipping a lot of this other stuff much quicker.

One of our big bugbears has always been our content authoring system. We've talked about this in recent months as well, and the new in-app editing system is nearly done! There are a few things arriving before the full change set, such as the new content server required to make this possible at all. The new content processing servers (what we refer to as the "depot") is being deployed to live right now. Our next EP release will support the new depot, including differential uploads. There are other things in there to speed up processing times as well.

The real focus though is this NextGen content architecture that is being backported to CurrentGen, and will enable full content editing in the viewer itself without Unity editor, including uploading and publishing assets. When thinking about this though, we've been thnking about how we gain closer parity to what the Unity editor offers, including lightbaking. To that end, we have brought the Blender Cycles engine into the desktop viewer and this lets you do a full lightbake in place, including all the furniture added to the region after it was uploaded. Bake it just as it is, as you see it now. Will support multiple lightbaking profiles for different stylistic looks.

We've also been looking at other useful things for creators. A good example is cloth physics, which looks really pretty, but is very laggy. We've built a new cloth proxy system that takes the cloth as it is, renders it as a lower resolution for physics precision, and then upscales it back to how it was. This greatly reduces the physics budget required. We're calling this new system "SpeedCloth", and is designed to work with the existing cloth architecture. You can continue to make cloth exactly how you do now, and this system will take it and convert it to run on the new system for you automatically.

What else... a new lighting system! The upside to this is that it is fully volumentric based on atmospheric scattering (how light travels through air). Light doesn't travel through the air unmodified, it changes, it passes through a medium, and that's how you get haze and other aspects of real lighting. Targeting support for low end devices with the new lighting engine, but there are limits to how low it will go of course. Hoping to ship this as a full replacement for our hodgepodge of current lighting and post effect solutions. Also includes a new sky rendering system, which is sort of a necessary freebie, including volumetric clouds. Not just limited to earth natural skies, it can do multiple suns and play with the amotpsheric conditions to simulate other more exotic places, like other planets. Will likely replace the existing 'Sky' button in the room editor which you are probably all familiar with already.

Adam has burnt an incalculable amount of AI tokens on trying to push this to finish, and it is close, but exact timeline is "when it is done" as usual. We are actively running validation on about 100,000 items randomly downloaded from our existing Sinespace assets, slowly working out any rendering or other content problems. After this, we should never need to do content correctness checks anymore, since it'll be entirely our own system and not subject to Unity changing things.

⏹ Expected date for an alpha viewer?
⏺ We have a lot of 'alpha' viewers now. Most likely the Unity 6 alpha viewer will be coming sooner than later, it works, just need to finish content processing. This is being targeted for our next release, which we refer to as Indigo internally.

⏹ Are consumables built into NextGen?
⏺ Kind of, it's more a scripting feature in NextGen, but it can be done through inventory servers as well. You can create the ability to use consumables, but it's different than just a fixed component you slap on there. You can also create databases and other features which may supplant the need for consumables directly, by having more flexible and more portable user-bound data.

⏹ If we have a product in Unity 2018 that can wait for Unity 6, should we wait for a Unity 6 EP to migrate or go ahead and migrate to Unity 2020?
⏺ This is up to you, ultimately. There's no "should" here. Whether you're coming from 2018 or 2020, we will support it into Unity 6, just like we always carry all content forward from even older Unity versions than that.

⏹ If we can modify things in client, will we be able to pull them back down to Unity if we want to?
⏺ Theoretically yes. The representation we've built is actually super portable. We have to make sure this doesn't become a super easy piracy mechanism though, to download someone else's content and plop it into Unity. In theory, it can definitely be done though. Likely a GLTF/similar export from the viewer for content you have specific permission for. Whether you have permission for it may become complicated over time, especially if something you made is a modification of something someone else made or is otherwise dependent on someone else's content (such as your script talking to someone else's script).

⏹ Any chance for pet system improvements in CurrentGen?
⏺ We would love to. Adam has periods where he is trying new AI systems that often include unlimited or otherwise large quantities of random free tokens to test things out, and something like the pet system is a good example of a low risk thing to experiment on to get improvements at the same time as testing is being done. Ideally, would like to see 1-2 page documents submitted to us that detail what you'd like to improve with more specificity.

⏹ Are there any updates coming to vehicles?
⏺ Oh boy, are there! A side project for Joshua over the last month has been overhauling the way our vehicle system works at several different levels. The first is a complete, homebrew replacement for Unity's standard WheelCollider as being stuck with Unity's means we have a lot of limitations that we're also stuck with. One example is Unity's wheel collider only lets you read the current rotational speed, you can't override it. This is important for things like proper differential locks, etc, where how fast a wheel turns is influenced by factors outside of the wheel itself. Our modular vehicle system is going to continue to support the standard Unity WheelCollider, so older vehicles will not be broken, although in the future we may automatically migrate them to ours instead. But for now, you can use either.

In addition to a new ModularWheelCollider, we're adding support for proper drivetrain mechanics. Engines with customizable torque curves, RPM ranges, etc. Transmissions with customizable numbers and ratios of gears. Differentials with locking and limited slip support, including support for multi-differential setups like center diffs. This will remain fully backwards compatible with existing vehicles, as well. The current vehicle mechanics are basically hub motors, and we're not getting rid of those. You can mix and match hub motors with the other drivetrain options if you want for some interesting hybrid vehicle approaches, or stick with pure hub motors if that fits your vehicle better.

We're not forgetting other kinds of vehicles either. The drivetrain changes also apply to boats and hover vehicles, with optionally-drivetrain-dependent propulsors and prop shafts.

Thank you for everyone who was able to attend and especially those with interesting questions to ask, we look forward to seeing you in the next one!