.png.efb555f51bdbf5136818509e6b53954f.png){kind=spacer}
NaomiLocket
-
Posts
93 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by NaomiLocket
-
-
You would need to do something with windows API calls and VBA, or an equivalent.
-
Pay very close attention to the RegionSayTo's throttle limit for channel 0. If you trigger that you'll block all your script projects from working with it on the whole sim. So if you decide to keep using channel 0 you'll want to work out a failsafe delay of some kind.
-
1
-
-
Afaik Linden Lab actually does lock threads. All of them at the same time. And have done so possibly at least twice.
When there is a major upgrade or change in forum software and shift everything to an accessible archive.
-
Alternatively. Nvidia have long since published titles like GPU Gems. :B
Complete with both opengl and direct x shaders for every example.
Dynamicly moving hair was as old as voodoo3 cards if I remember right at all, but for a time only tomb raider and few others ever seemed interested in implementing it. -
21 hours ago, Da5id Weatherwax said:
And this is another area where a skilled content creator at the Lab could make a huge difference.
Thing is they never had to look very far. There have been several forums dedicated to artists in the industry as long as secondlife. The problem is more if they can be assed to go looking for an artist with the goods to be a consultant. Hell some of them have long since written custom shaders for viewports in popular 3D modelling programs. It wasn't unusual for a studio to make plugins for either Maya or 3D max as a tool directly in their pipeline for making a game. And now and then they would share their more private time things with the community. The challenge for them is if they can find someone available at the time at those places. The challenge for us is to be sure they are actively recruiting instead of hoping someone is going to bother to come to their site and request a job.
When the usual stated response to people talking to outsiders about second life is "that is still around?" as a running joke, my optimism that any of them would bother chasing down the Lab for a job stays fairly low.
-
Triangle strips are mostly about consolidating that index into the shortest size in as few drawcalls. It doesn't mean we don't have an index of verticies, however. There may be other reasons behind why strips are not working presently or maybe appear to not optimise like they are supposed to. I still feel it is a grave error that they are not seemingly to work or be used. (perhaps the sorting is the first place to look)
-
8 minutes ago, ChinRey said:
This is a bit of idle speculation but is it possible SL uses triangle strips for the ground mesh and only the ground mesh? I did some tests on the beta grid and didn't see any difference neither in the looks or performance of a bare patch of ground with triangle strips switched on or off. That was perfectly flat ground so it may not mean anything but the ground mesh is one of the three SL assets where triangle strips would make the most sense.
Yet it might mean something, because the sides of a generated prim are also completely flat. But the setting references the wrong indexes in the list visually for the strip and crosses over a whole row to form a triangle. Causing conflicts, on top of the every second being inverted normal issue. So maybe it is actually a thing.
(also the point of forming degenerate triangle strips is so that submeshes that are normally split are no longer split and form a single triangle strip. Meaning it makes sense to form strips where ever and on what ever it is possible)
-
That is hopeful news at least.
-
1
-
-
13 minutes ago, Wulfie Reanimator said:
It's not like Linden Lab is getting a free pass here either. I regularly see the regulars (here and elsewhere) calling out Linden Lab's neglect. Even if we did assume that triangle strips weren't being used, that would only strengthen (for example) my argument that shaving those excess tris and optimizing the heck out of your model is very important. The current state is just not acceptable, no matter who's at fault. Things could be so much better, from LL and the creators' side. Actual games -- modern or old -- have never used assets like the ones you see in SL, even with modern technologies doing a lot of the heavy lifting. I know I made a list here of various games and the reported model stats, but lord knows if I can find it again..
Game assets are a bit fluid. They don't all suscribe to the same theory. As an aside on lists and stats of figures used. I gave you two figures used in heavier titles that appear in other peoples lists and articles.
In one of the art forums, heaven help me to find it just like you and your list, was a speciliased shader that made use of extensive splits in UV to benefit from critically small memory in the actual texture. Go figure, high splits would normally mean bloated "verticies" but the UV soup actually worked. It was based on a square enix publish of deus ex. But I imagine the thing would be built to handle that. I wouldn't recommend causing splits without a desired reason. But modularity and repeats on custom geometry has a distinct appeal to it.
(eta: of course we could use the technique as a middle part of the workflow and bake down to a publish. but that would lose the small texture size.)
-
Well maybe someone can. I heard a rumour someone supposedly compiled under Vulcan and got twice the rate. But when I saw that happen with that setting I figured, if that rumour was true, chances are they did more than just simply compile with a different library. I speculated maybe they fixed that problem for starters.
Well maybe someone that is familiar with the codebase can sort it or help us understand what is exactly going on and where we are at. Anyway, thanks for at least taking a look at it seriously, Wulfie.
-
6 minutes ago, Wulfie Reanimator said:
This was a good read, thank you. I got through the whole thing, but.. I don't think a single thing I've said has contradicted anything the author says. Especially the "From Fat to Flat and Big to Small" section is something I've beaten my drum about (though not as eloquently). Correct me if I'm wrong.
The whole article does a good job of highlighting SL's biggest problem/struggle; lack of context. Most assets are created in a vacuum, as standalone products. The vast majority of creators on SL are not creating uniform, controlled environments, and they lack the tools to properly figure out what the problem areas are even if they do try make their own original areas like a game developer would.
I'm glad you liked it. I liked it too, find it fascinating even. I take it with a grain of salt, though, because every studio team is different on a vast timeline and they all develop differently. Consider sorting algorithms and a google engineer interview. I certainly picked this one because it felt partially dated but still modern enough. And the concepts are fairly solid and concepts age better than some other things.
Yes, historically there was one time I went off the rails on purpose in a particular thread to see how far some usual suspects would go. And I raised that point myself on people creating for the context of the asset not the location. But that is a natural thing here. It doesn't negate the responsibilty the Lab has to us in code. 99% of everything is at the mercy of it. It doesn't change the fact that artists are at the very end of the blame spectrum.
Which Eric subtly pointed out. He was a technical artist in the middle of artists and programmers and told the artists to ask the level designer. Because they outlined the requirements.
The merchants have customers. I imagine from casual observation there is sometimes as much trouble talking to merchants as customers as there are artists talking to programmers. But not always, some of them are actually kinda nice!
Second life is like. Well. A very dysfunctional studio of hybrid level designers and artists.
But if people give up getting the Lab to treat content management, rendering pipelines, and their data structures as an artform itself we will never see it improve as gamers have seen theirs improve constantly. And it isn't like the Lab hasn't done work ever. They talk about it now and then when they have something significant.But it has been sixteen years. I mean really.
-
1
-
-
Yeah exactly. I turned that debug setting on from false (which it was defaulted) and my display on both mesh and generated prims became corrupted in terrible ways. Ways that it shouldn't. If you can explain any condition I can adjust myself that could be the cause, that would be appreciated. I don't doubt OpenGL, I know it is a library. I know it supports features and handles some things natively. And I also know that an application vendor actually has to make use of it, not just compile it or just write glsl. They have to actually implement some application level code. (which I know you know)
Seeing as you've just linked a feature in a previous build. I'll just tell you now without a screenshot. I turned on the option and noticed the "problem". So I wanted confirmation. This is suggesting that it did not and favoured lists.
-
1
-
-
18 minutes ago, Wulfie Reanimator said:
You're gonna need to get some sources to back that up, if you're implying that triangle count doesn't matter (or even as much). Draw calls and texture memory have also been the subject on these forums many times and they're all important, none of them should be ignored. Draw calls aren't something we can affect much though, so it's talked about the least. The best we can do is use less materials (faces) per object.
There is literally no reason why I should have to provide sources in a sea of people feeling to debate optimisation. They should have already researched it and either be able to provide additional information or simply accept it.
But as you wish, here is the opinionated helpful tips of one dude from one studio. That happens to be linked from the Polycount forums. That happen to be an active art community that is industry focused and participated in the old domination war competitions that were to scout up coming talent. That also happen to be among the groups that were into the whole limited sub 150 triangle mini speed competitions as well. IMO small triangle targets are back in fashion mainly for three things. 1) Practice 2) Mobile and ARM 3) Stylisic reasons.
Mr Eric talks drawcalls, texture memory, transform vs fill bound. and blame shifting you should take with a grain of salt but some truth.artists talk among themselves. Also a link to a nvidia white paper. because industry.
-
1
-
-
6 minutes ago, Wulfie Reanimator said:
Shaving off a couple hundred of them from one of your products isn't going to seem like much, but when lots of copies of that product are appearing on the screen, those ignored optimizations literally multiply. You should always assume the worst-case scenario and the more you (general you) do it, the better SL as a whole will run for everybody.
That matters when the engine works as it should. Bending the work to work for an engine that runs like sand instead of fuel in the tank just means in general we suffer the performance and lack of enjoyment no matter, always. It won't improve for as long as people pretend there isn't a problem with it and bend content to those problems.
As a contrast, Digital Extremes reworked their IP and built their own particle engine from the ground up when they didn't like the direction a vendor went for their purposes. On the same hardware not only did they give twice the graphical goodies but also twice the performance. SL can barely handle thousands of particles, but they can do millions.
On the same hardware. I am just going to double stress that point.
-
1
-
-
1 minute ago, Wulfie Reanimator said:
You're gonna need to define what you mean by "triangle stripping." I can't tell if you're talking about reducing them or this.
The latter, the wiki link.
The basic fact has everything to do with it. The card manufacturers and Nvidia in particular along with the studios over the years have explicitly gone to that direction. That is why crysis boasts 3 million triangles for a scene and handles fine for its target. That is also why the larger ships of star citizen were rumoured to be ~7million on their own. They don't care about the triangle count. They care about how they are used. Which is also why a lot of factors actually cull the amount of triangles processed anyway. Triangle stripping makes the draw calls efficient. It batches the work. The more that exist and are put in the strip for efficiency is where the optimisation is. Not the total number of them.
Shaving off triangles for 4fps is a waste of effort and time, and that is why they go more for things that impact to a greater extent - in code..
-
1
-
-
Also if I remember from previous readings on complexity and display metrics. There was no mention of it actually representing the work "your" card load is doing. Just that it uses this feature, that feature, and comes up with a "figure". Our rending load changes with the wind of our camera direction. Which is more a level designers direction than an individual asset.
I guess Penny does partially imply that in the OP at least.
-
1
-
-
Before anyone keeps beating the optimised horse, I'd like confirmation if triangle stripping actually works in secondlife like it was supposed to since 2005. If it doesn't I don't care for any opinion on triangle counts and optimisation. Triangles are the base unit that all modern cards are made to handle best at great quantity. The industry went to great length to make it that way. They are more concerned about draw calls and memory when it is texture bound issue (but not always). So. Does second life triangle strip effectively and properly including using degenerate triangles for the same material?
-
1
-
-
Try just a little harder
-
13 hours ago, OptimoMaximo said:
The impediment isn't in the cutting, Maya impedes the formation of "left over" geometry if that geometry doesn't make a face.
Ah, I am guessing that very impediment and lack of it sits before the differences in cutting then. Being able to have that leftover geometry and manipulate or correct it is an intermediary step. I always liked the feeling of being able to cut anywhere and make a face anywhere at any time.
-
3 minutes ago, ChinRey said:
I think I've mentioned this at least twice here and I try not to repeat myself but I once met a professional 3D modeller who was looking at Second Life as a place to build what he wanted to rather than what the movies and games he usually worked on asked him to. I don't think he even said hello before he asked "Why are meshes in Second Life so high poly?"
Did you point him in the direction of the graphics preferences, shaders, state of the opengl implementation, and the asset design principles SL banked on? If he is a professional, he'll answer his own question in less than a minute.
-
On 1/11/2018 at 4:36 AM, OptimoMaximo said:
Really? I thought this was a shared feature in the two softwares. Maya impedes that instead
I don't know how much things have changed by now, but Max typically had better poly cutting tools out of the box that impeded less too.
-
Oh there has been, just not as well disseminated, but that isn't your point. Thank you for the clearer picture. I am well aware of our limitations to affect the code to a point, where it counts, but that also plays into why I still push for the code. If we get so efficient at compromises and taking forever to do things as efficiently as possible, we eliminate any reason for the code to change. We've gone through these many years with selection highlighting unable to cope with the systems sheer size of vertex data, in some cases (and so needing to turn it off to return to performance). It is not like certain things have changed regardless of being efficient or not. I am pretty sure there has been an ancient article somewhere on how to engineer application code to more efficiently use shaders for exactly the purpose of handling selection feedback, vaguely. While we do not control that, we do have the needs, and there are benefits to be had.
I don't agree with the practice of those trees, however in principle, and I understand your efforts and need. I wasn't too keen way back when clothing tools were being discussed simply from seeing the resulting topology, and knowing how the system tends to be in general. While I do stand somewhat on the clumsily logician side of things in these topics, I would still keep to "reasonable" application and freedom of design. Partially because of the rigidity of the system itself. Outside of some aspect of the systems rigidity, yeah sure, I agree.
Perhaps somewhere down the line, a more relatable example and demonstration. Something that solves a particular, or couple of, constraints of the system, that may itself influence the decisions and principles in its construction. And demonstrates in general a wider performance gap. Though I'd like clarification on what the FPS counter is actually counting. I heard it wasn't strictly rendering performance, and included most if not the whole of applications activities.
Your example in the other thread, making purposeful dual use of the shadow plane, is actually a decent point to keep people thinking about the how's and why's to do something a particular way (Even if ALM comes with its own shadows).
-
By and large yes. This is why I tend to push more to optimisation and performance through code first, before we push for people to be too picky with their triangles. Once there is a better foundation and a reasonable offering to work and build with in the first place, then being fussy about triangles matters more. Not just for performance considerations, but the responsibility becomes more mutually shared in general.
Facilitating good practices helps waste less effort in promoting them. When we know full well people are up against three levels of shader programs of radically different appearances that every asset is bound to. Given that actual uploads not on the test grid are fixed copies, monetising oneshot database entries almost wordpress publish style (where have we heard that not long ago), we can not define multiple geometries based on graphics preference (you need more triangles for vertex shadow painting), and the upload process is generally painful, people will always take shortcuts. Even if they can or know how to do better. It's a time management and sanity thing.
I was actually happy to hear animesh was happening. Instantly knowing there would be (hopefully) less reason to alpha/mask flip. Instantly reducing the amount of links and geometry needed for given effects. A step in the right direction. It sadly should have been on the design before SL went public, given UT 03/04 at the same time, and general shared features that were largely pre-existing concepts.
-
1
-
-
41 minutes ago, ChinRey said:
Even that may well be overanalyzing.
But wild goose chaes aren't always a waste of time. You may not ever find what you're looking for but who knows what else turn up along the way?
You do have a point there
and there was certainly some interest.
Facebook
Instagram
Twitter
YouTube
Flickr
Communicating between two objects
in LSL Scripting
Posted
Arbitrary can help sure, but a guarantee is better I think.