Jump to content

Proposal - FAST MESH


Coffee Pancake
 Share

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

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

Recommended Posts

29 minutes ago, NaomiLocket said:

That seems to be a gross overstretch of the imagination.

Which part? That people say and believe those things? Or that content in Second Life is really that badly made?

31 minutes ago, NaomiLocket said:

There is nothing wrong or incorrect with expecting a developer to actually do software engineering.

 Look, I'm just about the furthest thing here from an LL apologist. I'm sure that there are issues with SL's code that could be fixed to make it run better.

But I'm also a graphics professional and know for a fact that badly made content creates another bottleneck. SL can, and already does, run much, much better when you optimize the content you build a sim with, and you don't load up every avatar with a million triangles and a gigabyte of textures. And SL's performance problems will not magically go away if you ignore the way content in SL is being made, and blame it all on "bad code".

  • Like 2
Link to comment
Share on other sites

2 minutes ago, Penny Patton said:

But I'm also a graphics professional and know for a fact that badly made content creates another bottleneck. SL can, and already does, run much, much better when you optimize the content you build a sim with, and you don't load up every avatar with a million triangles and a gigabyte of textures. And SL's performance problems will not magically go away if you ignore the way content in SL is being made, and blame it all on "bad code".

The problem is that code comes first. Everyone knows that. Performance is entirely at the mercy of code, it always has been. It dictates how data is handled. As a graphics professional you also know that. You also know that there is more to art and context than a blanket "this is bad and not optimised", because you know what a budget is and basic math. Hiding the problem with overly reduced content is not optimising or addressing any underlying problem. It's also not in line with necessity being the mother of all invention either, that happened and the lab found single points of failure or that people had memory leaks and crashed visiting stores and not because the mesh was bad. There are probably areas we'd find to agree with, but I won't agree with blowing a problem out of proportion, that doesn't mean that I am not aware there are meshes so dense in the wireframe you can't see through them but it also doesn't mean that it's crashing my tiny ass 2gb card either - because it's not using excessive memory.

Yes, people have made content in ways I would not. Some content 'less poorly' made lagged my system more so than high density mesh that is beyond what I would make, because that is the raw nature of the content and code that acted on it. Half the people that rail against someone for a high detail LOD, don't properly understand what a high detail LOD and what the rest of the LOD system does and just abuse someone to the point they delete threads - and go back to the professionals instead where they have accounts.

You need to be more flexible on optimisation and remember that more than one road leads to rome.

Link to comment
Share on other sites

1 minute ago, NaomiLocket said:

The problem is that code comes first. Everyone knows that.

SL's problems aren't in the code. They are fundamental design decisions and key to SL. Take them away and replace them with resulting "better code" and we don't have SL anymore. We have Sansar, and that went so well you're still here.

You're basing your entire argument on some pretty huge assumptions about not only how all this works, but why it works the way that it does.

Everything SL allows you to do comes with an associated cost. Much of that cost is systemic, unavoidable and happens way before rendering even starts.

It is not realistic to expect SL to perform like a game, or even for the same rules to apply. If SL's problems could be fixed by "better code", someone would have yanked a game engine off the shelf, bootstrapped SL's fully open source login code to it and we would all be buying them cakes. That having happed exactly zero times after 18 years in this hole should tell you something.

Keeping a lid on content complexity is one of the biggest sticks we have.

 

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Coffee Pancake said:

SL's problems aren't in the code. They are fundamental design decisions and key to SL. Take them away and replace them with resulting "better code" and we don't have SL anymore. We have Sansar, and that went so well you're still here.

You're basing your entire argument on some pretty huge assumptions about not only how all this works, but why it works the way that it does.

Everything SL allows you to do comes with an associated cost. Much of that cost is systemic, unavoidable and happens way before rendering even starts.

 

That is mostly untrue, but you are entitled to your opinion. Finding performance improvements in code, or changing how you approach an existing problem has literally nothing to do with sansar or abandoning SL, at all.

As for "gently punishing people that don't do how they want to do it" they already do through counting UV splits as extra verticies. They don't need to go further, and it isn't even entirely correct as demonstrated externally to SL that you can in fact build entire sims on a fraction of the texture use by increasing splits. You're preaching to the choir and missing too many marks.

(ETA: fortunately there is an alternative method to splits that can reduce exposure to that budget penalty, but that comes at a cost to freedom and its own limitations.)

Edited by NaomiLocket
Link to comment
Share on other sites

1 hour ago, Coffee Pancake said:

It is not realistic to expect SL to perform like a game, or even for the same rules to apply. If SL's problems could be fixed by "better code", someone would have yanked a game engine off the shelf, bootstrapped SL's fully open source login code to it and we would all be buying them cakes. That having happed exactly zero times after 18 years in this hole should tell you something.

 

Again, if it wasn't for people with TPV's challenging the status quo, you wouldn't have advanced lighting and better materials in all 18 years. They did, and so you do.

  • Haha 1
Link to comment
Share on other sites

What's untrue is your assertion that performance is dictated solely by the code. Any game artist would tell you that's absolute nonsense. If performance was entirely at the mercy of the code and nothing else then optimizing a game's art assets wouldn't be necessary at all. Retopologizing mesh made in sculpting programs wouldn't be necessary. Normal maps wouldn't be necessary. LOD wouldn't be necessary. These are all tools to optimize art assets for realtime 3D rendering.

At the very least now I don't have to point at other threads for an example of the kind of nonsense I described in my original post.

Link to comment
Share on other sites

8 minutes ago, Penny Patton said:

At the very least now I don't have to point at other threads for an example of the kind of nonsense I described in my original post.

Actually you do, because regardless every year every studio will progress to higher detail to write home about in their favourite magazine as they have always done. I never said they don't rework art assets to meet the balance between technology and a given software engineers teams capability. That was never asserted, but it was a nice attempt to make something up. Be more professional next time and expand your horizons across more studios - they've even written books about how to publish once for every platform in the past. People just didn't like the outcome of that kind of performance. :)

Edited by NaomiLocket
Link to comment
Share on other sites

2 minutes ago, NaomiLocket said:

I never said they don't rework art assets to meet the balance between technology and a given software engineers teams capability. That was never asserted, but it was a nice attempt to make something up

This you?

2 hours ago, NaomiLocket said:

Performance is entirely at the mercy of code, it always has been.

 

  • Like 1
Link to comment
Share on other sites

Just now, Penny Patton said:

This you?

 

That is, and it is true. If you explore sorting algorithms you will not argue about it or make a logical fallacy. You would also not try to miss-represent it if you understood a file on a disk or in memory.

Link to comment
Share on other sites

At the end of the day, you work within the constraints of the engine, you don't ignore those constraints assuming that it will just "get better" in the future.

You don't just get to reverse the balance because you're a petulant Second Life creator. Every game artist understands this very well: you work with the tools you are given.

  • Thanks 2
Link to comment
Share on other sites

And to be clear this isn't just a problem isolated to SecondLife, this is a problem on the unity asset store, on turbosquid, on every single marketplace where creators are effectively shielded from peer review or supervision (like when working under an artistic director) and are only beholden to the person purchasing their work.

  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, Kyrah Abattoir said:

And to be clear this isn't just a problem isolated to SecondLife, this is a problem on the unity asset store, on turbosquid, on every single marketplace where creators are effectively shielded from peer review or supervision (like when working under an artistic director) and are only beholden to the person purchasing their work.

I would agree with you on balance, but not on strict principle. You're trying to apply a standardisation to a dataset that is already in general already standardised - but there is no such standardisation to a programmer. Yes there is peer review, but there is also revision history for a reason. The industry giants with art directors get this, which is why Digital Extremes reworked Warframe and rebelled against Nvidia's particle direction writing their own, because they could do it better and were long due to give back to the community that gave to them. And they did. They did not make excuses about it and come up with some nonsense that they had to overly punish art creation itself. They did the job.

Now I am going to stress, my rebuttal to you is not quite a rebuttal. It is mild for context, and specific. I am for performance and optimisation. And there will for sure come a time I will come across the very thing "some" of you are up on arms about. Just like when some land barons write out about some little feud that seems funny, then you see people doing the very things. It doesn't matter.

What matters is that the culture here is wrong on too many points. Attempts to assert a rigid nonsense that is demonstratably actually against the industry or buried so far in the past it only exists for stylistic reasons. And instead of making themselves more employable or better mentors, insist of trying to tell people they should be finantially put out, the task made harder, or some other nonsense that doesn't apply. To boot they even forget SL's own history and try to recite it to me (hense Exodus viewer).

There are better ways to approach the issue. If it were true that a "well known creator" happened to "break the grid" as such, they would no longer be here, and they would be instead infamous.

Link to comment
Share on other sites

1 hour ago, NaomiLocket said:

To be very blunt, if you read a 2GB text file all at once, you are to blame, not the text file.

That's a logical fallacy if I ever saw one. You can read a 2GB text file in chunks if whatever algorithm you're running on it allows it. If you want to draw a model then you need the entire model and textures in memory, preferably the graphics card's. Yes, texture streaming is a thing. But you still gotta render whatever is on screen.

Furthermore, there are numerous bottlenecks that have nothing to do with the game code, but the GPU's pipeline and the connection to the rest of the system. If the memory bus can't keep up, you get long delays before a high-quality texture can be rendered. If you fill the VRAM with unoptimized abominations, it will cause the GPU to either give up entirely or fall back to, for example, system RAM.

Bottom line, performance is also at the mercy of what you do with/to the graphics pipeline. And the performance of that , in turn, is heavily impacted by the content you wish to draw.

Had two courses about this kinda stuff. Who'd have thought it would get useful in the SL forums of all places?

 

  • Like 3
Link to comment
Share on other sites

1 minute ago, FinnfinnLost said:

That's a logical fallacy if I ever saw one. You can read a 2GB text file in chunks if whatever algorithm you're running on it allows it. If you want to draw a model then you need the entire model and textures in memory, preferably the graphics card's. Yes, texture streaming is a thing. But you still gotta render whatever is on screen.

Furthermore, there are numerous bottlenecks that have nothing to do with the game code, but the GPU's pipeline and the connection to the rest of the system. If the memory bus can't keep up, you get long delays before a high-quality texture can be rendered. If you fill the VRAM with unoptimized abominations, it will cause the GPU to either give up entirely or fall back to, for example, system RAM.

Bottom line, performance is also at the mercy of what you do with/to the graphics pipeline. And the performance of that , in turn, is heavily impacted by the content you wish to draw.

Had two courses about this kinda stuff. Who'd have thought it would get useful in the SL forums of all places?

 

Your first paragraph argued against itself, re: admitting that ID software were indeed correct, you can protect against it.

I don't argue that much about bottlenecks, they are everywhere. A lot of them before your art asset is ever a consideration in fact. Agreed what you do with the graphics pipeline has a lot to do with it. Which is also the very point that you can take a small file and make it a larger one at runtime easily - which has nothing to do with an artist. A technical artist can explain that, they also write code. It is good that you took courses, I also did. That doesn't make either of us experts. But I will point out, that I appreciate you expanding on my information. I only hope that you understand the gravity and weight of it, and the responsibility of good code (including shaders).

Link to comment
Share on other sites

1 minute ago, NaomiLocket said:

Your first paragraph argued against itself, re: admitting that ID software were indeed correct, you can protect against it.

I don't argue that much about bottlenecks, they are everywhere. A lot of them before your art asset is ever a consideration in fact. Agreed what you do with the graphics pipeline has a lot to do with it. Which is also the very point that you can take a small file and make it a larger one at runtime easily - which has nothing to do with an artist. A technical artist can explain that, they also write code. It is good that you took courses, I also did. That doesn't make either of us experts. But I will point out, that I appreciate you expanding on my information. I only hope that you understand the gravity and weight of it, and the responsibility of good code (including shaders).

I write code for a living. Not in the graphics department, but certain principles still apply.

Also, it's great that id did it. But as a content creator it is your job to make sure you work WITH the engine, not churn out stuff that bogs it down and then insist on changes in the implementation. Sure, you can ask for features or optimizations. But as long as you're not absolutely certain these features or optimizations will be available to you, it's your responsibility to create stuff that works with what is there right here and now, even if it is suboptimal. Especially since we are in a productive environment here, where stuff that is created by both LL and the community directly impacts the (paying) users.

Since we're using other companies as an example, UE4 has a beautiful implementation of global illumination. That doesn't mean I get to yell at LL for not implementing that feature to make use of it.

I also appreciate the civilized discussion.

  • Like 2
Link to comment
Share on other sites

1 minute ago, FinnfinnLost said:

I write code for a living. Not in the graphics department, but certain principles still apply.

Also, it's great that id did it. But as a content creator it is your job to make sure you work WITH the engine, not churn out stuff that bogs it down and then insist on changes in the implementation.

That is however a two way street. If your studio CEO tells you, you will let his artists do more, you will or find another studio. Subsequently ID's CEO was right to tell his team they have every reason to be proud of what they had accomplished. Even when speedrunners were exploiting both code execution and level design. Right 100% that they should proud of what they accomplished. It is not just the artists that have to work with the constraints. You can have situations where you have worked under the constraints. A bad shader will alone will still wreck the scene regardless of the rest of the program. An engine is but one code revision. A engine that does not revise slowly makes its way to the hearts and minds of the retro. Not a bad thing in itself for the love of history and a childhood. We all do it. Emulators are awesome also.

I am not saying they should adopt a particular engine. I am saying, people need to leave artists to last which is the only sane thing. There are multiple points in SL's history across different people involved that have found a given issue and fixed it. They write about it, and it is commendable. It is also a bitter victory when you consider how many years SL has suffered a given point of failure or a terrible server configuration. You will not inspire artists to do better here or to think of this place first instead of last, if all you do is tell them to put up with the engine.

They will not listen to that, and have every reason not to.

At least the LSL mentors are more helpful, generally.

Art is as a subject unto itself, only held back by programmers that wish they were the programmer sitting next to them.

Link to comment
Share on other sites

There is no game out there where the kind of mesh creators in SL output is "normal".

And yes, without pressure, bad creators who make a killing on sales aren't going to listen, because sales are the only metric of whether they are doing well or not.

  • Like 3
Link to comment
Share on other sites

1 minute ago, NaomiLocket said:

That is however a two way street. If your studio CEO tells you, you will let his artists do more, you will or find another studio. Subsequently ID's CEO was right to tell his team they have every reason to be proud of what they had accomplished. Even when speedrunners were exploiting both code execution and level design. Right 100% that they should proud of what they accomplished. It is not just the artists that have to work with the constraints. You can have situations where you have worked under the constraints. A bad shader will alone will still wreck the scene regardless of the rest of the program. An engine is but one code revision. A engine that does not revise slowly makes its way to the hearts and minds of the retro. Not a bad thing in itself for the love of history and a childhood. We all do it. Emulators are awesome also.

I am not saying they should adopt a particular engine. I am saying, people need to leave artists to last which is the only sane thing. There are multiple points in SL's history across different people involved that have found a given issue and fixed it. They write about it, and it is commendable. It is also a bitter victory when you consider how many years SL has suffered a given point of failure or a terrible server configuration. You will not inspire artists to do better here or to think of this place first instead of last, if all you do is tell them to put up with the engine.

They will not listen to that, and have every reason not to.

At least the LSL mentors are more helpful, generally.

Art is as a subject unto itself, only held back by programmers that wish they were the programmer sitting next to them.

Sorry, but the last part is absolutely messed up.

You're creating art for an interactive experience that is expected to be smooth. You can't just claim you're being held back by programmers and be done with it. If one thinks it's justified chucking HUGE amounts of model and textures at people and then going "Ah, but the engine should be SO MUCH BETTER", at this point it's not even an engine limitation anymore. No matter the engine, 1 GB of textures for one single models is entirely not feasible for any hardware but the most high-end stuff.

Quite frankly, I find your disrespect for programmers a bit insulting. In fact, I recently received a video by an artist, it was supposed to play in an embedded context. However, the system lacked the resources to properly decode it, resulting in stutters all over. And you know what? Instead of yelling at me to buy better hardware or write my own optimized media player, he edited it to be easier on resources. Ya know. Working with the limits of the system.

It's alright to report bugs and it's okay to be furious about bad performance. It's not okay to go "FINE! I'm going to make everyone's experience suck until LL fixes it!". That's called a tantrum.

Link to comment
Share on other sites

3 minutes ago, Kyrah Abattoir said:

There is no game out there where the kind of mesh creators in SL output is "normal".

And yes, without pressure, bad creators who make a killing on sales aren't going to listen, because sales are the only metric of whether they are doing well or not.

Not quite. If it grinds their own system to a halt or doesn't fulfill a purpose most of them aren't going to kill their own brand with it. There are some use cases where small bevels can be found in big titles. Just not "everywhere". But they do, do it. But you're arguing extremes contextually that are lost in scaling. They are making a killing because they made something someone wanted. It worked out long term and someone was a repeat customer, or they were not. Actual artists do have peer review.

Yes I get you can make x thing, throw it out there with a price, and someone gets said thing. This is still not the way.

Link to comment
Share on other sites

7 minutes ago, FinnfinnLost said:

Quite frankly, I find your disrespect for programmers a bit insulting. In fact, I recently received a video by an artist, it was supposed to play in an embedded context. However, the system lacked the resources to properly decode it, resulting in stutters all over. And you know what? Instead of yelling at me to buy better hardware or write my own optimized media player, he edited it to be easier on resources. Ya know. Working with the limits of the system.

You mistake disrespect for programmers with understanding reality and the difference between good programmers and not so crash hot ones. There is a fun little programmer joke that says "You don't need artists, you only need programmer art." Artists don't cry over it. Boo hoo. It means there is a minimal need for execution ie: proxy art. Various levels of art happen after. If you have not reached the limit of your style guide you have not finished polishing your product up to the time limit for production. So the work does not stop until then.

Good luck with that "disrespect" out there. All you did here was tell me you're going to bring up the rendering of a video as some how a thing, when that is completely to do with programmers and nothing to do with the art asset it rasterised. That is what is off kilter. It doesn't relate at all in any way to the asset that is in it. It could have been the best or the worst it doesn't make a difference to choosing better compression. Why did you even go there?

Link to comment
Share on other sites

2 hours ago, NaomiLocket said:

To be very blunt, if you read a 2GB text file all at once, you are to blame, not the text file.

or

ducks.jpg.8fef180ecc4a2daa25046af8682443e7.jpg

is clearly something wrong with this scooter. Other people can easy get two or even three times as many geese on their scooters

😺

  • Like 1
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

Just now, Mollymews said:

or

ducks.jpg.8fef180ecc4a2daa25046af8682443e7.jpg

is clearly something wrong with this scooter. Other people can easy get two or even three times as many geese on their scooters

😺

I want to apply three different reactions but I'm going to have to settle for just the one. Not my fault ;)
I do like your tongue in cheek post, though. props.

Link to comment
Share on other sites

6 minutes ago, NaomiLocket said:

I am presuming you will next go: aha, gotcha, it was one of those fancy render a 3D object on a webpage natively. As if the web browser dictates a 3d model for other engine contexts.

Since you're  presuming stuff now for the whole purpose of mocking me for an argument that I DID NOT EVEN BRING UP, nor was I planning to, I think we're done here.

Back to topic, I actually thought of something else. Zeroing out LODs is, something that should remain, even if strict tri limits on custom ones would be enforced. There's a performance advantage to be had when not rendering small things at long or even medium distance at all.

Link to comment
Share on other sites

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

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

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
 Share

×
×
  • Create New...