CrystalFrostViewer

Another progress update on rigged meshes

Ok, we've got meshs almost figured out. As you can see here the mesh's vertices are now properly enveloping the mesh, so the placement is correct... There are some issues regarding which joint is which, however, and some other minor gotchas that need to be worked out.

7th of February, 2024 rigged mesh progress report

I'm continuing to try to figure out what's going wrong with the rigged meshes.

It seems the math we have for how the skeleton should be arranged is not correct.

Now we need to figure out why exactly this is happening.

More progress update on rigged mesh

So having played around with what we've got so far, I've come to the conclusion that the problem with the rigging right now is that the vertices are likely offset from where they ought to be, resulting the skeleton being outside the body.
Spooky invisible skeletons and it's not even Spooktober yet.

Mesh rigging progress

Here's the current state of rigged mesh progress. This was tested on Second Life, but the data is more or less the same with OpenSim, and we are also doing lots of testing on OpenSim as well.

There's still some issues with the rigging, but it's coming along.

Some visual progress on rigged meshes

Some good folks at the Open Sim AvatarLife grid have been working on rigged meshes. A lot of the hold up is just reverse engineering which I've been helping them with.

It's not much but progress is being made on rigged meshes. There's some kinks to work out still.

Textures on prims are still not working yet but I promised myself I'd get it done by this coming Monday.

Progress Update

The project has some developers who are going full bore on porting CF to mobile and they're also working on solving puzzles like cracking rigged and fitted meshes. Once they are done the code will be backported.
Open Sim's reference code now has PBR support and hopefully that means LibreMetaverse will support it too. I'll likely be dropping attempt to support RenderMaterials once PBR is in LibreMetaverse because CF has always used PBR materials.
In the mean time I continue my work on getting the overhead down, but I have to fix texture loading on prims for that to really work.

Fixed bug on varregions

So there was a bug when you logged into a varregion where nothing would happen. Literally nothing. No terrain, no objects, nothing. This was being caused by an unhandled exception. The problem has been fixed.

Note to self, put custom shaders in Resources folder from now on.

Source for build 5.5 released to Snowcrashed

Snowcrashed users should now have access to the current state of the code as of the time of this writing. There's a lot of under the hood changes for efficiency and code management. Also this source is more up to date than the build 5 which was released 2 days ago.

It'll be in the code-snapshots channel of the discord, which is only available to Snowcrashed users. The files are all too big for posting directly to Patreon.

Patreon Release 5

PLEASE NOTE: This release is primarily about testing stability updates when logging in to OpenSim grids. Some things have broken since the last update. The reason is because the systems involved are currently being overhauled for stability and efficiency which is absolutely a necessity if Crystal Frost is going to be useable on anything but high end systems or any grid other than the official Second Life grid. Thank you for your patience. Most notably, texturing is currently broken. I apologize deeply for this, it is currently being worked on.

To download, you'll need to be a patron at Jacked-In or Snowcrashed level and then go to the #patron-updates channel on our discord. I apologize for not posting it here.

Things are very stable, even on Open Sim, but the texture loading system is currently broken while it's being worked on to support the new, far more efficient method of creating meshes.

Also it is now possible to set the grid login URL from within the viewer at the login screen, so you no longer need to use bat files or short cuts to log into an OpenSim grid. Eventually I'll have it set up to save grid URLs that you've used, but this should be quite usable as it is for now.

October update

A breakthrough has been made in getting rigged mesh to work. Sliders for fitted and bento won't be supported right away however.

The breakthrough is that I can now access the weight data for mesh assets. I need to write the code to decode the data and make sure it'll actually weight, however.

The Unity "runtime fee" will not affect the project

First off, let me just say that there has been an absolute shitstorm... nay a shithurricane of misinformation regarding what Unity has said. People watch videos, they look at screenshots, they didn't see the original announcement, they aren't developers themselves, and they're just believing propaganda being posted by people it doesn't even affect.

The original table was taken out of context and everything exploded from there. The context of the original table is when you go over both thresholds for the fee to apply to your games.

Then people are acting like it would bankrupt anyone. It was at most a $0.20 fee. Even in the original version, if you're making enough money and have enough installs for it to apply to you, it only applied to installs after you reach the threshold, not retroactively to all prior installs.

That's all about the original version of what was said, before any of the backpedaling and clarification that Unity did on the matter.

Now, let's put this into perspective, shall we?

Subnautica 2 is about $30. Let's just assume they would have to pay the highest rate on the original chart, and use the initial clarification that it only applies to initial installs by a user, not to literally every download (it's absolutely absurd to think it would be every individual download, or that piracy would count). Someone buys the game That's $0.20 out of $30.00 which for that game would mean a 0.6% royalty rate past $200,000 of revenue.

People said they were jumping ship to Unreal. Well, guess what. If your game qualifies for the runtime fee for Unity, it qualifies for the royalty rate that Unreal charges past a certain revenue point. That's a 5% royalty. So they're basically if their game costs $30, they're saying "I can't afford an 0.6% royalty, so I'm jumping ship to Unreal and paying a 5% royalty."

Surely paying almost 10 times as much is cheaper, right?

So how does any of this affect Crystal Frost?

It doesn't. I haven't made over $200,000 by selling copies of Crystal Frost, and I never will because once Crystal Frost is ready for actual release, it will be provided for free. The patreon is just to help fund development of it, and I don't expect the patreon to ever cross that threshold.

Successful test of a VarRegion.

Wolf Mountain in the Wolf Territories Grid. Some quirks...

1: Framerate is really low for a while as it does the terrain patches. Some optimization will be needed. I've already done some optimization, but it only really smooths things out rather than improving the framerate.

2: Camera does not attach to the avatar and thus I need to figure out a different manner of detecting which object is the avatar. This has been a known problem with connecting to OpenSim.

Hopefully I'll have this #2 sorted and a test client ready by Friday.

Public progress update for August

I've finally got some progress to report.

First of all, I've got adjacent sims and their prims loading. First screenshot shows that, but you can see gaps between the terrains of the 3 sims. Second screenshot is from the opposite angle, showing the terrain being stitched, so no more gaps now.

Second, I don't have any recordings of it yet, but the'll be coming in the next few days, physics objects now move a lot more smoothly. As such so do avatars. Previously there was an illusion of it being lower framerate than it really was due to some bad math on predicting the movements of objects, but that's been fixed.

I'm currently waiting on LibreMetaverse to update their library to include some recent changes we've submitted that allow for the extra data from OpenSim VarRegions regarding their size. Once I have an updated LibreMetaverse I'll be able to integrate it. In the mean time I'm going to work on cleaning up avatar appearance, but I suspect it'll only be a few days at most before I have an update for it.

Further updates in August will be patron only.

Quick status update, and why progress is slow

Currently the patreon is just over $300/mo. My rent is about $1200/mo and utilities are about $300/mo. Food is about $200/mo. Not counting taxes which are 30%. So in order for me to work on this full time I need about $2430/mo before taxes on Patreon to be able to afford to work on this project full time.

As it is, what's coming in is only enough for me to be able to afford to work about 3 days a month on it. If I divert time away from other paying gigs to work on it past those 3 days, I end up not having enough money for rent and utilities at the end of the month.

I'm trying to squeeze free time into it, but my free time is in very limited supply. Until winter I can only squeeze 1 day a week out of my free time because that's all I've got. I should be able to squeeze out more free time in the winter though, but it still won't be enough to get a lot of work done.

I can't do this without your support!

Avatar shape sliders are working!

It was a pain in the butt to make it handle multiple sliders simultaneously, but I got it working! At this point, all that's left is to implement the sliders that modify bone scales like arm length, leg length, etc, fix the rigging, and implement animations.

Varregions are still in the works, still waiting on the code submission to LibreMetaverse.

End of June 2023 Update

We've got the protocol for handling VarRegions on Open Sim submitted to LibreMetaverse and will be able to begin implementing it into Crystal Frost once it goes through. In the mean time I've been resuming work on the base Linden avatar. Just early this morning I had a major break through with rigging. It should be able to be rigged correctly but I can't test until tomorrow because I have to attend an event committee today with an anti-child abuse organization I volunteer with.

If the rigging goes well, then I should be able to release an update for better avatars (no animations yet) by the end of next week. Possibly with shape slider support but no promises on the sliders just yet, but if not it'll be in the update after that, probably by the end of July.

Linden Base Avatar is now rigging

The base avatar is now able to be loaded and weighted at runtime, which means it's ready for animating. While the Bento Skeleton is in fact loading, only the pre-bento skeleton is currently supported in the code, at least for Ruth (which is what I'm calling the base avatar, mainly on account of "Ruth" being the name of the default stripped down avatar on Second Life).

There are some issues, but they're unimportant at this time. Basic functionality is what's required right now, not perfection.

Next I have to work on getting the morphs / blend shapes working so that shape settings can be applied.

After that I'm going to get to work on supporting adjascent sims and varsims.

Once adjascent sims and varsims are supported I'll move on to decoding SL's animations for animating avatars. Hopefully by then the person I assigned the task of getting other avatar meshes working will have some results for us.

Proper Rigged Avatars Support Soon!

Here we have the standard Linden Lab base avatar that is what you see when you take off all your meshes and alpha channels on Second Life. Crystal Frost can now load it direct from the stock files that Linden Lab distributes with their viewer.

These avatar files are distributed by Linden Lab as LGPL, meaning it's legal for Crystal Frost to include them directly, and include them it shall.

What you also see here, as white lines, is the Project Bento skeleton that made such a huge stir when Linden Lab first released it for Second Life.

The avatar mesh is not yet rigged to the skeleton, but I'm hoping to have that figured out in the next couple of days. In addition, I also have to get the morph targets working.

Once all of that is done and working, I will be moving the code over into Crystal Frost's avatar rendering system and it will, at the very least, allow for attachments to show up in the correct places on avatars.

HOWEVER, I will also be releasing a free library for Unity developers to be able to use the Linden Lab base avatar meshes in their Unity projects. Not that they're all that great of meshes to use, but as a free resource to create widely varying, mobile friendly avatars and characters on the cheap, it's not a bad starting point. I say mobile friendly because they're very low polycount by today's standards and only have a single bone per weight.

Also, can you imagine walking around as the base Ruth avatar from the Second Life library inventory on VRChat? That'd be a riot.

Patron Build 4 and Source release

New build released for Goggled In and up. Only new feature in it is that glow should be working. Sky, Water, and rez effects are currently disabled. It's released primarily to see if anybody can find any more crashes now that the last crash has been isolated and the code that caused it disabled until it can be rewritten.

Also source code snapshots are now being made available to Snowcrashed level patrons.

Please make sure your Patreon account is linked to your Discord account and view the relevant channels in the discord to get access to the downloads.

"Weekly" update about what's going on

I apologize for the info dump, I just wanted to let everyone know why there hasn't been an update recently, and be very transparent on what's going on.

So, just to keep you guys informed about what's going on.

There are three types of main types of updates that SL sends regarding objects other than avatars. ObjectUpdate, ObjectBlockUpdate, and TerseUpdate.

Now, the Linden based viewers like Firestorm all just feed those updates in pretty directly into the existing data structures, which is honestly the most efficient way to handle it.

HOWEVER

We can't do it that way because we're using Unity, not a Linden Lab based engine

I've tracked down a major crash bug (it doesn't technically crash, it just goes into a death spiral where each frame takes longer and longer, but if you wait long enough technically a new frame will happen) to rapidly changing data in texture faces

Like for example if a script is constantly cycling the color of a texture face, it'll cause the crash.

This crash is occurring because there's no real way to determine what data exactly has been changed at all, if any of it, so Crystal Frost is just going ahead and applying all of the data in the update even if it's the same, without checking if it's the same, because checking it would be using conditionals when it's often just faster to ignore them...

I mean 

if(x!=y)x=y; is slower than just going x=y because the conditional takes more cpu time than just going x=y;

But in this case, there are some things it's doing that a conditional would actually speed things up...

BUT to do those conditionals on the main thread would dramatically kill performance vs if no updates were coming in at all

So we're going to have to do more under the hood work before the next Patreon release, to do all that checking on a separate thread and then send the main thread very specific update packets, telling it exactly what to change.

That way the main thread, which handles rendering won't have to do many conditionals, nor will it have to update things that aren't performative to update JUST because an update came in.

Patreon Build 3

A few things going on in this update. First of all particles should be mostly supported. Particle targets (such as used by leashes) aren't implemented yet, nor are particle ribbons as well as a couple of other minor settings such as wind and emissive.

Another thing is glow was fixed and deferred rendering is enabled, but but the glow only works in the editor, not in this stand alone build. Also hud rendering is broken due to the deferred rendering. I'm hoping to have those sorted in the next build or two.

https://drive.google.com/open?id=15tyKzKaD6u2G6H3TAht7m_1cYfrCAUKd&authuser=myraloveless%40gmail.com&usp=drive_fs

Web link for patreon preview build 2

As in the last post, this build is primarily about a massive performance enhancement but also fixes a catastrophic bug regarding an as yet unsupported texture type that is so rare that I'm surprised anybody encountered it. Still, it's been fixed!
https://drive.google.com/file/d/15rggW_FDjn-t-t5c7uqVHR68QIdx0v8Q/view?usp=sharing

Onward to squashing more bugs and implementing more features. Build tools are up next!

Patreon Release 2

This update is kind of minor. Just a major performance increase as well as fixing a bug reported by a patron. Details and file in the discord for now. I'll put the file on the web and make a post for patrons with the URL later tonight.

First Patreon Preview Release

This is an alpha version release for Patreon users only please do not distribute to the general public, and please make bug reports in the patreon bug reports channel on the discord.

An alternative version would be https://drive.google.com/file/d/15dgAbM1uWPZdtSyaFY2K8L89HQeSfDdM/view?usp=sharing

This alternative version has dynamic draw call batching which MIGHT result in higher frame rates. Also it has support for alternative login URIs to allow open sim logins. I forgot to include that ability in the initial release which is the main reason for the alternative one.

One final demo of water prims.

Nothing has really changed, I was just trying to fix sculpted prim rendering and orphan prim handling, got that done, then I rezzed a sculpted boat and put it on a pivot box that slowly rotates to try to demo what it would look like to have a boat moving through the water system employed by Crystal Frost. This demo is using a very large water box, but the results would be pretty much the same in sim water.

To accomplish this demo I simply made a giant water box  and then rezzed "Bubba's Boat" by Aley and added the #SPLOOSH tag to the description field of the hull, then linked the boat to that spinning wood box in the middle of the water and gave the box an llTargetOmega script to spin slowly which reads the following:

default{

state_entry(){

llTargetOmega(<0,0,1>, 0.1, 1);

}

}

To explain what I mean by "orphan prim handling", the server doesn't always send the root prim of an object to a viewer before it sends the child prims, so sometimes a bunch of prims (includes sculpts and meshes, they're both treated as types of prims) will have a parent but the parent hasn't even rezzed yet. I had code to cause them to parent when their root showed up, but it wasn't working right.

Colorable Water Prims

Water prims now obey the color setting of face 0 of the prim with the water prim tag.

So best way to make a water prim is this. First make a box in Second Life. Second, give it what ever textures and water you want to use as the fallback for other viewers. Heck you can even use an animated texture, it doesn't matter.

Color the texture to what ever color you want the water to be. Using a color that's close to the color of your texture would be best. In the above screenshots I'm just using a blank texture and coloring it. For best results make sure all sides are the same color. That makes it easier to ensure that you're getting the right color.

Feel free to adjust the transparency of your box. More transparency will make your water clearer, less transparency will make it more murky.

Next position and resize your box. Then add the tag #WATERBOX to the description field of the general tab of your box.

Do NOT cut, twist, skew, hollow, or otherwise torture the box. If you do, it'll still be just a regular box. Using other prim type will also result in just a regular box. Support for other prim types and tortured prims will happen eventually, it's just not right now.

Anyway, just resize it, position, and rotate it. When rotating it you might want to make sure that the side it was originally created with facing up is always facing up, otherwise funky results can happen. It won't break anything but it can have unpredictable results.

Next, any objects you want to interact with the water should have the tag #SPLOOSH in their description.

That's it.

SPLOOSH!

Not only does Crystal Frost have water prims, which LL refuses to implement, but they knock it out of the park and smash a window of a car in the parking lot outside the stadium. The water is realistically refractive as you see in this and previous videos showing the water, but they do real time caustics on the surface of a pool you put them in. Plus... the water is interactive. Also sim water is interactive too!

All avatars have the water interaction flag set already, but objects have to have the #SPLOOSH tag set to them. It only works for the specific object it's set to, so if you have a multi-prim boat, you don't just set it to the root unless the root is the hull of the boat that will sit in the water.

The strength of the wake is affected by the size and velocity of the object moving through the water.

I have a fairly low end system by today's standards, with only a GTX 1060. So bear that in mind with the framerates you're seeing in this video.

Progress report and de-rez effect preview

Today I got a lot done. Figured out a lot of problems that have been irking me for ages. Such as being able to retrieve object name and description, as well as avatar name. Once those were done, I made it so that Crystal Frost will display nearby chat in its chat log... and THEN... I made it so that the sun position syncs with what the sim says it is...

Having crushed it, I decided to do something a little special as desert. Here's a video showing it. When objects are de-rezzed, they don't just instantly pop out of existence. Instead, they dissolve out of existence!

Object Updates

Objects and child objects are now updating their position, rotation, and scale. I still have to implement prim torture and face changes. Prim torture changes shouldn't be too difficult, but changing faces might be a bit harder.

First successful test of exploration.

The avatar, which is the grey box, can be moved around now. The other tall, grey boxes are likewise other avatars.

Avatar rendering is a ways away because it requires alot more than I currently have.

It looks lower framerate than it is because there's no interpolation of movement.