Jump to content
Kyrah Abattoir

Why beginners don't learn the basics first?

Recommended Posts

7 hours ago, OptimoMaximo said:

SL can't keep up with these standards change because of its internal architecture.

That OpenSimulator exists is a counterexample. OpenSimulator is completely different code than SL's system, but speaks the same protocols to the viewer. OpenSimulator is in C#; SL's sim code is in C++.

Share this post


Link to post
Share on other sites
On 2/6/2019 at 12:02 PM, Kyrah Abattoir said:

Linden Labs is not responsible for making your content. As much as you hate making lod meshs, that is very much your job as the artist.

Linden Lab (with no s btw.) does supply the basic tools though. That is their responsibility.

I do understand very well Motoko's point of view and he is fundamentally right. One of the main keys to SL's initial success was that everybody could build here. It's far more consumer focused today of course but DIY is still very important.

Yet LL never provided adequate mesh building tools for beginners.

Imagine somebody running a go-kart track and their customer keep asking for more power. So they buy a couple of formula 1 cars (old ones with faulty brakes is all they can afford) and expect the customers to figure out for themselves how to handle them. That's essentially what happened when LL introduced mesh and all things considered, it's not generally a good way to do things.

Edited by ChinRey
  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, ChinRey said:

Linden Lab (with no s btw.) does supply the basic tools though. That is their responsibility.

I do understand very well Motoko's point of view and he is fundamentally right. One of the main keys to SL's initial success was that everybody could build here. It's far more consumer focused today of course but DIY is still very important.

Yet LL never provided adequate mesh building tools for beginners.

Imagine somebody running a go-kart track and their customer keep asking for more power. So they buy a couple of formula 1 cars (old ones with faulty brakes is all they can afford) and expect the customers to figure out for themselves how to handle them. That's essentially what happened when LL introduced mesh and all things considered, it's not generally a good way to do things.

You do have a point, the transition from prims to sculpts, to mesh was painful for a lot of people I knew who ended up just leaving. We also did lose something big with mesh, and that's that collaborative vibe we had, and that insurance that any object you made was made by residents, for residents.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
45 minutes ago, Kyrah Abattoir said:

We also did lose something big with mesh, and that's that collaborative vibe we had, and that insurance that any object you made was made by residents, for residents.

You almost made me cry there, Kyrah. I was lucky enough to catch the tail end of the prim buiding era and yes, those were the best days of my Second Life - no doubt whatsoever.

But those days are gone, the sooner we accept that, the better. I joined SL permanently in 2013 and I recognised the place from my first cameo visit back in '05 or thereabouts. Oh, there were lots of changes on the surface but it was still fundamentally the same. Today it is very, very different - more serious, less fun and far less exciting.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, ChinRey said:

But those days are gone, the sooner we accept that, the better.

I very much agree with everything else. This one sentence though, I'd like to offer a gentle suggestion on, if that's acceptable.

It's simply this - of course we have to work with what SL's given us re mesh, but we can also do our utmost to keep space for and help facilitate co-operative working and DIY within those constraints.

Share this post


Link to post
Share on other sites
4 hours ago, Bitsy Buccaneer said:

It's simply this - of course we have to work with what SL's given us re mesh, but we can also do our utmost to keep space for and help facilitate co-operative working and DIY within those constraints.

There's no disagreement there really. One of the most important things to do to achieve that is to assess and accept the current situation to see what we can do about it.

Share this post


Link to post
Share on other sites
On 2/8/2019 at 7:38 PM, animats said:

That OpenSimulator exists is a counterexample. OpenSimulator is completely different code than SL's system, but speaks the same protocols to the viewer. OpenSimulator is in C#; SL's sim code is in C++.

And how does that exactly fit within the context of assets encoding? What you describe is another architecture issue, in which someone makes the system work using two different languages communicate together. The actual context of my intervention is how assets are being encoded, try to change that and everything (read: assets) would go bananas instantly, while adding more on top, like creating a new type of asset, adds up over an issue that sees the CPU not having much more wiggle room to handle things, as stated various times by Beq Janus in other threads.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, OptimoMaximo said:

The actual context of my intervention is how assets are being encoded, try to change that and everything (read: assets) would go bananas instantly.

There's some interest in the OpenSimulator community in making a viewer that's based on Unreal Engine 4 but plays SL-format assets. The asset format isn't that complicated. It's a subset of what modern games support.  The only really incompatible part is scripting. The OpenSimulator people already have an LSL interpreter, so that's covered.

(A modern version of SL might be a UE4 viewer on the front end, OpenSimulator on the back end, SpatialOS for scaling, funding from Epic Games's new $25 million fund for big MMO worlds, and a program to identify the top 100 creators in SL and get their permission to move their assets to the new system.)

Share this post


Link to post
Share on other sites
9 minutes ago, animats said:

There's some interest in the OpenSimulator community in making a viewer that's based on Unreal Engine 4 but plays SL-format assets. The asset format isn't that complicated. It's a subset of what modern games support.

Interesting, and i really would love to see that. However, the issue from my intervention still stands. You refer to code that reads/writes (upload) assets, that can be done using any programming language that supports C struct capabilities, even python. The issue at hand is more about changing that encoding architecture NOW in SL (breaking everything) or ADDING a new asset class with its own new encoding, or just a modified/extended child class.

  • Like 1

Share this post


Link to post
Share on other sites
7 minutes ago, OptimoMaximo said:

The issue at hand is more about changing that encoding architecture NOW in SL (breaking everything) or ADDING a new asset class with its own new encoding, or just a modified/extended child class.

You'd probably want to use FBX format, which is the de-facto industry standard for game assets. Autodesk defined it and their tools support it. Unreal Engine 4 supports it. Blender supports it. Lots of assets are available in FBX format. Converting SL assets to FBX wouldn't be all that hard.

Share this post


Link to post
Share on other sites
6 hours ago, animats said:

You'd probably want to use FBX format, which is the de-facto industry standard for game assets.

For streaming efficiency it may actually be worth it to have a dedicated file format for mesh with a client side converter to whatever the viewer is happy with. Even an xml variant may reduce the streaming cost significantly compared to any standard mesh format.

The reason is that SL mesh is a rather simplified kind with only 32x10 bit vertice coordinates, 32(or less)x2 bit normal coordinates,16 bit vertice and triangle addresses and 8 bit (or less) material addresses. Any file format made for more complex mesh system is bound to include a lot of superfluous data that still has to be transferred.

Edit: To put it another way:

  • Each vertice of an SL mesh can be defined by 58 bytes of data
    • 2 bytes address
    • 8 bytes for each of the uvxyz coordinates - 40 in total
    • 16 bytes for normal direction (or is that 32 - brain suffering from coffeine deprivation right now)
  • Each triangle requires 9 bytes
    • 2 bytes address
    • 6 bytes for vertice allocation
    • 1 byte for material allocation
  • Each material: 52
    • 1 byte address
    • 3 byte RGB color (I can't really understand why it needs that but apparently it does)
    • 48 bytes UUID addresses for diffuse, normal and specular maps

There is some overhead too of course and I may have overlooked a few parameters - but many.

More advanced meshes need more bytes for addressing/allocation, more bytes for coordinates and also data for paramteres not suported by SL mesh. It adds up to a lot and this is actually a rare case where the game industry as a whole may ahve something to learn from how SL handles meshes.

Edited by ChinRey

Share this post


Link to post
Share on other sites
On 2/10/2019 at 8:29 PM, animats said:

You'd probably want to use FBX format, which is the de-facto industry standard for game assets. Autodesk defined it and their tools support it. Unreal Engine 4 supports it. Blender supports it. Lots of assets are available in FBX format. Converting SL assets to FBX wouldn't be all that hard.

FBX is non-free

Share this post


Link to post
Share on other sites
24 minutes ago, Kyrah Abattoir said:

FBX is non-free

According to the old Mesh FAQ page SL's internal mesh format is more than 95% as compact as COLLADA. That is actually very impressive. According to a thread at the Unity forum FBX has even bigger file sizes than COLLADA.

So no, we do not want to replace SL's internal mesh file format with FBX!!! Yes, I know I keep complaining about all the mistakes LL made with mesh but let's also give them credit for what they did get right!

What format the mesh is uploaded in is a completely different matter of course. It can be anything as long as the uploader is able to interpet it and convert it into copact SL mesh.

Share this post


Link to post
Share on other sites
On 2/10/2019 at 8:29 PM, animats said:

You'd probably want to use FBX format, which is the de-facto industry standard for game assets.

While it is with no doubt the de facto standard, you need to understand that network traffic is better off with a format that is not text based. SL-s internal asset is written in bynary, which translates in a file that has a limit of 8 MB size, including LoDs and the max vertices count

8 hours ago, ChinRey said:

According to a thread at the Unity forum FBX has even bigger file sizes than COLLADA.

This clashes with my personal experience about it. If this may be true for static object, let's not forget that both FBX and Collada are full scene exporters, and a true comparison can be done only when also animation-related data is included. I see this pretty much everyday, since my workflow includes export to fbx and conversion to Collada using FBX converter (although i'm told Maya can now export perfectly acceptable .dae files, this habit of mine still persists from the early days of mesh when Maya collada had some clashing against SL's collada expectations): a rigged model in FBX is WAY smaller in size than the same scene in Collada, whereas the fbx is just around 700KB, the collada counterpart reaches the tens of megabytes, and things get definitely worse when blendshapes and keyframes are involved. Let's not forget that fbx is Autodesk's take on Collada, tweaked to suit and support proprietary softwares' specs and scene structures: fbx supports geometry grouping, collada doesn't for example.

Then, there is also this:

9 hours ago, Kyrah Abattoir said:

FBX is non-free

There's need for an SDK and a license to support fbx in your own application. Reason why LL chose the rather inexpensive Collada. If the viewer wasn't opensource, they probably would have used fbx.

On 2/11/2019 at 2:41 AM, ChinRey said:

More advanced meshes need more bytes for addressing/allocation, more bytes for coordinates and also data for paramteres not suported by SL mesh. It adds up to a lot and this is actually a rare case where the game industry as a whole may ahve something to learn from how SL handles meshes.

Many game engines already internally handle meshes in a binary format. Reading the documentations, you can pretty easily find limit numbers set as 65536, which is the most important clue to interpret it as "we binary encode this data, this is the limit". The only example of this that is coming up to my mind right now is UE4 limit on keletal meshes number of joints, which is 65536 and Unity clear statement about their internal asset encoding that is binary.

  • Like 1

Share this post


Link to post
Share on other sites
On 2/10/2019 at 1:53 PM, animats said:

(A modern version of SL might be a UE4 viewer on the front end, OpenSimulator on the back end, SpatialOS for scaling, funding from Epic Games's new $25 million fund for big MMO worlds, and a program to identify the top 100 creators in SL and get their permission to move their assets to the new system.)

Where are you sourcing the people who'd be interested in it from?

Share this post


Link to post
Share on other sites
6 hours ago, OptimoMaximo said:

This clashes with my personal experience about it. If this may be true for static object, let's not forget that both FBX and Collada are full scene exporters, and a true comparison can be done only when also animation-related data is included.

You may be right but maybe I misunderstood what you are discussing.

I wasn't trying to claim that COLLADA is better than FBX but that both are heavy file formats.

What file format content creators upload the file in is trivial when it comes to performance since it's only done once for each mesh. There may be other reasons why one format is better than the other, such as compatibility with other software. I have no opinion about that.

The format used to transfer meshes from the asstets server to the viewer is a completely different matter. That transfer has to be done every time a client requests a fresh copy of the mesh and it takes a lot of bandwidth. According to the documentation, the proprietary file format Second Life uses for this is far more suitable for streaming individual, SL style (that is simplified) meshes than either COLLADA or FBX. I take LL's word for it of course but for once I'm perfectly willing to do so unless somebody has better info to offer.

The architecture for the SL mesh format is published here btw. It doesn't go into details of course but should still give a good idea what it's about. And looking at it, yes, there seems to be some room for further refinement.

(Digression: Yes, rigging was implemented right from the very start but apparently LL had no intention of using it for anything until some content creators took matters in their own hands. Go figure.)

Edited by ChinRey

Share this post


Link to post
Share on other sites
5 hours ago, ChinRey said:

I wasn't trying to claim that COLLADA is better than FBX but that both are heavy file formats.

They're both text files and as such, they may be heavy and not suited for network streaming, the point is that between the two, if there was a choice to be done, fbx would be better because generally it ends up being smaller than collada. 

 

5 hours ago, ChinRey said:

The format used to transfer meshes from the asstets server to the viewer is a completely different matter.

Yes i know, i was about writing a custom exporter for Maya some time ago, after my animation exporter was done, and i did research SL mesh's internal architecture. I found out it was something impossible to achieve because some required data needs to be written to file on upload by the uploader itself in a specific location of the file, so i dropped the idea altogether, it wasn't worth it. The specs say that the final binary encoded file would have a max allowed size of 8 megabytes and contains all LoDs, physics and all materials as mesh subsets, but again some data needs to be filled in post-import (like the havok physics). It's very streamlined and it's for sure the best way to stream a mesh object over the net, compared to a generic text file such as fbx or collada.

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×