Jump to content

Why beginners don't learn the basics first?


Kyrah Abattoir
 Share

You are about to reply to a thread that has been inactive for 1365 days.

Please take a moment to consider if this thread is worth bumping.

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++.

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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.

Link to comment
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
Link to comment
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.)

Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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

Link to comment
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.

Link to comment
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
Link to comment
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?

Link to comment
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
Link to comment
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
Link to comment
Share on other sites

On 2/10/2019 at 7:53 PM, 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.  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.)

Classic opensim, they have so many features missing on the server and now they want to rewrite the client.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

This topic is pretentious.  People come from all different backgrounds with different levels of expertise, from beginner to intermediate to expert.  Some people just want to create for fun, others for profit.  Some people can't afford Maya or Max, so they use Blender, and the plethora of tutorials out there for Blender, is enough to confuse any beginner.  It's as if you're expecting people to find tutorials from professors with graduate degrees in 3D and Animation.

As someone already stated, new SL users want to create for SL, not any other specific 3D program such as Unity or UE4.  When's the last time you've searched for SL mesh tutorials though?  Because it's completely fragmented with many outdated and new workflows.  There's the old classic avatar creation process, standard sizes, liquid/fitted mesh, and now mesh bodies, heads, and appliers.

This is LL's fault though, for not keeping the base avatar system up to date.  They have completely abandoned the in-world building tools and workflow, so now the userbase has to rely on 3rd party programs for mesh creation.  It was a lot easier when designers only had to rely on Photoshop or GIMP for skins and textures, because those programs were 2D, not 3D.  New creators and designers have to learn modeling, rigging, weight painting, avastar, 3D texturing, etc.  It would take at least 6 months or longer to learn all that proficiently.  I don't see many people sticking around that long to learn all that.  This is why i only see the same handful of stores from 5+ years ago, because they already have the knowledge and expertise that they developed over those years.  Creating for SL was much simpler.

Edited by Nextio
  • Like 1
Link to comment
Share on other sites

2 hours ago, Nextio said:

As someone already stated, new SL users want to create for SL, not any other specific 3D program such as Unity or UE4.  When's the last time you've searched for SL mesh tutorials though?  Because it's completely fragmented with many outdated and new workflows.  There's the old classic avatar creation process, standard sizes, liquid/fitted mesh, and now mesh bodies, heads, and appliers.

People keep pulling that pathetic excuse that they want to create "for SL and not any other specific 3D program" like SL is some sort of snowflake where texture and polygon budgets somehow don't exist, and in the process thumb their nose to all the knowledge put out there by people who actually know what they are doing.
Rigging is a bit special with SL yes, but I've never talked about rigging being the issue. If anything that's the part most creators have nailed down. Modeling whether it's for SL, Unity, or god knows what engine is virtually identical.

2 hours ago, Nextio said:

This is LL's fault though, for not keeping the base avatar system up to date.  They have completely abandoned the in-world building tools and workflow, so now the userbase has to rely on 3rd party programs for mesh creation.  It was a lot easier when designers only had to rely on Photoshop or GIMP for skins and textures, because those programs were 2D, not 3D.  New creators and designers have to learn modeling, rigging, weight painting, avastar, 3D texturing, etc.  It would take at least 6 months or longer to learn all that proficiently.  I don't see many people sticking around that long to learn all that.  This is why i only see the same handful of stores from 5+ years ago, because they already have the knowledge and expertise that they developed over those years.  Creating for SL was much simpler.

Yes I look at the past too with rose tinted glasses, "back in the prim days", but things change and expecting LL to provide a full modeling solution within the viewer, is completely unrealistic.

This is not a tool problem, it's a people problem and a learning problem.

There is also a complete disconnect when people will happily blame SL for their performance issues, when the person standing in front of them with 200Mb of textures and an entire sim worth of polygons attached to their body, is the real problem.

Big creators will not change unless their sales suffer, and aspiring creators will keep walking right into their footsteps, seeing those people as the gold standard of content creation.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Fionalein said:

See?

Blender docs? Basically everywhere. It's the n°1 modeling tool used by hobbyists and indies.

Best practices? There is a lot of content you can download and study, this isn't 2001 anymore when everything was s trade secret, game modding has been going on for decades now.

 

Link to comment
Share on other sites

On 3/11/2019 at 11:16 AM, Kyrah Abattoir said:

Blender docs? Basically everywhere. It's the n°1 modeling tool used by hobbyists and indies.

Best practices? There is a lot of content you can download and study, this isn't 2001 anymore when everything was s trade secret, game modding has been going on for decades now.

 

Blender's documents are usually outdated and explained very poorly.  It also doesn't teach you how to be proficient, which is your original gripe in the first place.  It just teaches the basics on how to use the tool.  It's not going to teach you how to be better.

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1365 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...