Jump to content

Kwakkelde Kwak

Resident
  • Posts

    2,879
  • Joined

  • Last visited

Everything posted by Kwakkelde Kwak

  1. Hmm root prim or child prim shouldn't make a difference as far as I know, just the fact there's a mesh in the set. I think if you had left the scripts out of the boxes ( which is ofcoursenot going to happen, that's why you have those boxes in the first place) you would be looking at something like 12 prims instead of 24. Size should matter, but I've seen my boxes count as less than a prim at house sizes. These were basic boxes though, no hollow or twist modifiers applied. Anyway, for prim efficiency you did well I guess:) you got yourself a free chair.
  2. Looking at the picture, you are after a very small cylinder. If you aren't, just ignore this post. I'd advice to use a ring instead of a torus. Not only will the result be a real cylinder shape, it will have a fraction of the rendering cost. As far as I can think of without starting up the viewer, all deformations work the same as for a torus. ( to make it very small, hollow it and cut path, you can make 0.25 mm thin cylinders I think , with a point at one end though) I'm not a big fan of these micro prims, but that's off topic and rather irrelevant here:)
  3. There's this weird bug I have been experiencing with that physics from file button in the beta viewer I'm using..not sure if it's the latest viewer, but anyway... Click it once and things go grey, click it again and it works... maybe that's the case for you aswell...I'm happy you got it uploaded correctly and I bet so are you Oh and i think if you link three together they will only cost 2 prims on your parcel...
  4. The Prim impact is measured by a number of factors, including scale, since the smaller it is, the less distance it takes to flip to a lower LOD, which makes the render cost lower. That's why it went from 6 to 2. Best is to scale in blender yes, that way you will see right away what it will cost inworld. If this is inconvenient for some reason, you can set the scale factor in the upload menu, third tab, next to physics ( I forgot what it's called). I do this for a truck I am working on. I build it scale 1 to 1, so it makes sense when I build it, then I set the upload scale 20% higher so it matches SL better. (Not 50% or even 100% which seems to be the case for some 4 meter wide and 10 long cars on the grid:) ) Oh duh, you have a screenshot of the menu, the scaling is in "upload options"....
  5. I think Chosen's entire point is awareness, it's mine anyway. In a way by looking at draw weight or the directly related prim weight, you are already doing that. By mentioning the LODs you do so even more. Don't forget as you again stated yourself, the 40k is imaginary indeed. I bet a lot of models on the marketplace are using too many faces on the lower LODs, which means they have to be rendered without being seen. That's just as useless and wasteful as hidden faces on any LOD. Saying others make high poly models justifies doing the same is the same as the "if your friends jump off a cliff...." That's not an argument. If you think you do need the extra faces, now that is a reason. Just make sure there IS a reason:) The high poly weapon in a FPS is the one you would be wearing I bet, not the one 30 others are using on the screen. If it's always up close it is perfectly reasonable to add a lot of detail. This is also the case for SL I'd say. Anyway, I'm glad you say you might look into it a bit more from now on, in a lot of cases making the polycount lower doesn't affect the looks in a bad way, sometimes even the opposite as I already mentioned and as Chosen visualized with the legstrap. (the 10 sided strap will look clunky from medium distance though, since unlike the leg, you can see the edges..a reason to have a higher number of sides at medium LOD than on high? ) I'm sure you do a lot better than most on the marketplace, but this shouldn't be the norm I think. And to keep this post on topic... did you make a jira about the multiplier per object instead of per number of affected triangles already? This really makes the draw weight a bogus number...
  6. wiked Anton wrote: applauds the residents who went to all this trouble, but they shouldn't have had to, this all should have been taken care of by LL......and it totally pi__es me off that they continually seek the profit and feel to supply less and les, or at least shirk responsibility for their product. we maya a well just send them money every month for doing next to nothing Supply less and less? I don't see how you can state that, at all. The last year LL has given us mesh and a V2/V3 viewer that's very usable. Also I've noticed performance gains, although that might be something not everyone is experiencing. If LL makes 75M, which I doubt (that sounds more like revenues than nett profit) they wouldn't care about the 5400. The thing is they have other priorities. Now a PART of the community wanted deformable rigged mesh. I think it's great that can now be developed, thanks to a number of people paying for it. But they did so because THEY wanted it. And by raising the money they have shown LL they are serious. Even now it's going to be done outside the LL office, it's going to cost LL quite some resources to implement it into the viewer. That will probably cost a lot more than 5400.
  7. You never needed a UV map for the physics. What did change (and possibly is "unchanged" in the latest project viewer) is the fact the physics shape needs one of the materials from the visible models. This wasn't the case before V3.1 and it's without a doubt what's causing your problems. LL admitted it didn't make a lot of sense, so it's very possible they changed it back.
  8. No you are 100% right with the LOD, as you mentioned earlier already if I recall correctly. It all comes down to data processing cost. When you have your lowest LOD set to next to nothing, there's next to nothing to send to avatars and next to nothing to render for those same avatars, I bet you already grasped that. It's not a complicated, but a very big formula. The number of triangles make up the base cost of an object, but only at the LOD they represent, so the distance multiplier for LOD high is nowhere near as big as that of LOD lowest. So indeed you can "get away" with a huge amount of triangles for the highest LOD. The thing is: What do you want your model to behave like? Do you want very smooth transitions between the LODs? That means the detail will have to gradually improve going into higher LODs. Or do you want to make an object as detailed as possible when up close? Then you scrap the lower two LODs and can use enormous amounts of faces per prim equivalent. One way isn't neccecarily better than the other, they each serve a different purpose. One thing remains though, the less you use, the less it costs. I think you've struck something quite interesting, I don't understand why LL decided to make the multipliers multipliers by prim, maybe easier coding and faster processing, but it doesn't represent the cost at all, if I read the wiki correctly not only 400 of your faces, but a single one would quadruple the draw weight. Now that is just stupid:) Oh forgot to answer your question..duh Medhue Simoni wrote: So does the display number have anything to do with prim counts, or land impact? Yes. It does. Everything I wrote also applies for Prim weight. As they say in the wiki, the number you are working with is based on the triangles, the Prim equivalent has one more multiplier (a very small one ofcourse) and is directly linked to the triangles. This is what I make of it: From http://wiki.secondlife.com/wiki/Mesh/Mesh_Streaming_Cost Dlowest = R / 0.03 Dlow = R / 0.06 Dmid = R / 0.24 Dhigh = 0.0 These represent the LOD transitions (in one direction) The triangle count used for the draw weight uses the area though, so rather than in one direction it's measured in the area of a circle. ( π r²) So this is π * D[LOD] * D[LOD] removing a single triangle at LOD low allows you to add 64 in the highest then. I'm missing something though, since the maximum radius of LOD lowest doesn't exist.. does the viewer use 256 meters as a maximum then?
  9. Exactly what I said.... Professional modelling (something which isn't my job btw) works the same, except it can involve airports and hotels..multiple times....
  10. Medhue Simoni wrote: [...] And believe me, it takes alot longer to make animation than a model. ...] I do some animating and it takes lot less time than my modelling... that doesn't mean I am a faster animator or a better one or a slower builder or a worse or better one. All it means is I put more time into my modelling, you put more time into your animating...I'm sure your animations are a lot longer and more complicated than mine. Medhue Simoni wrote: [...] If I waste a hundred verts, I'm not that worried about it concidering what is currently considered efficient in SL. Overall tho, I doubt any1 can say my mesh are inefficient. [...] I think it's pretty inefficient:) But all kidding aside, I think now that we have a tool that lets us build efficiently, the current rediculous standards, where torusses and sculpts are the norm, should be canned and we should take advantage of the new possibilities. That doesn't mean everyone should dig and dig for weeks on end to find that last wasted vertice or face ofcourse, I agree. I rather see a lot of beautiful new meshes than a couple of beatiful ones which are slightly or even quite more efficient. Medhue Simoni wrote: [...] I didn't post my concerns to see who could be the best at reducing modelsI asked if the Draw weights seemed reasonable and I would appreciate it if we could focus on that. I know and I already said the 1100-4400 increase or whatwasit sounds high for making 400 faces invisible, test it on some other items and post a jira I'd say, this doesn't sound right to me at all, no matter how your model looks or is constructed. EDIT sorry for hijacking your thread, Chosen and I already stole another one..I'll try and stay there with the nitpicking about verts and tris and efficiency and tricks and all...
  11. The thing is not "yes I can reduce this or that" but "hey I can do without this data without changing a single thing about the looks. You say you have to make about 400 faces invisible. As far as I can see it's only the four flapping pieces, I made a duplicate and it costs me 4x64 faces, which is only 64%. Looks, exactly the same. This is what I ment. I can't argue on the balance of detail vs resources, but it makes no sense to me to waste so many faces on...well nothing but building convenience really. But that's just me, if you can build items that people like and make twice as many because you cut some corners....maybe you are better to the community than I am:)
  12. I think the 1 SL face makes no difference whatsoever, it shouldn't... the 1100-4500 for 400 faces sounds more like a bug to me than just being illogical. JIRA?
  13. Medhue Simoni wrote: Transparent items in a mesh take a very serious hit. Without anything being transparent on the tool, it's weight is 1100. With 1 SL face being tranparent, the weight jumps to 4500. That is illogical. That depends on the actual number of faces affected, to me it does sound rather high though indeed.
  14. I really replied for the 1000 points for the standard avatar. Medhue Simoni wrote: A high poly gun in the 3d circles could be 30k polygons, but in SL, 5k polys is probably considered high for a gun. At the same time tho, you need at least 1k in polys to get a decent looking gun with any detail. I'm not the polypolice, nor do I want to be:) But 30k polygons can not easily be justified I think. It depends on a great number of factors though. Some you have control over as a builder, some not. You can set the lower LODs to keep the pressure on the servers and graphic cards within normal proportions (whoever decides what those are). I have never built for games, but I really doubt the guns in shooters are 30k polys, that sounds like art, movie or stills numbers to me, as Chosen mentioned, you can let your computer do the rendering in an hour, a day, a week, not in a fraction of a second. As I told him, I don't think you can compare SL with a game one on one, for various reasons, but SL is certainly closer to games than to high poly modelling. There has to be a balance between how detailed the model looks and how much resources it takes, I'm not the one to tell anyone what that balance should be. LL is, to a certain degree, other than that every builder or user should decide for themselves what is acceptable or appropriate, taking in mind that what they wear DOES affect everyone around them. Do you want your model to look good when playing wargames or do you want it to look good on display? The two would result in different models I think. Furthermore if the object gets too detailed, it won't match anything around it, so all one accomplishes is making everything look bad, by making something nice... how odd is that? EDIT I see you edited in the picture, thanks:) I'm not suggesting you should rebuild the entire thing, but I see a couple of things that can easily lower the polycount. The strap for the holster you already agreed on, 1024 triangles is a bit much. The holster itself looks like it has got the entire inside modelled. I don't think that's the way to build it. Purple arrow..same as the holster strap, I think you won't disagree plus it looks like a bunch of faces are buried in the model, invisible unless you rotate your camera inside it. Green arrow..looks like you have one straight edge divided into several pieces, that's not nececary, joining the vertices won't affect the shape at all. Orange arrows..it's hard to see, but on the right arrow you have the flat circular piece with one vertice in the center, this uses half the faces of the similair plane by the left arrow. Blue arrow..Not sure, but it looks like you have hidden faces there. Circle...well I think even within a high poly model this is a high poly part, especially since most of it is partially hidden. I'm sure there's more, but they are probably similair to the ones I described. Anyway, i don't mean to put a "bad model" label on your object at all, just trying to show where things could be improved. I'm sure if I made an intricate object like that I'd have a bunch of parts that could be improved, so don't take it the wrong way.
  15. I'm not going to give a full reply on this, it will be more fun to let Chosen do that... One thing I have to say though. The fact LL only counts 1000 for the avatar is probably because (unless you want to kill your entire 5 year wardrobe) you have no choice. I would even say they could set it to zero. This doesn't reflect the costs, I know, it's a formula and you can't state 2000 is twice as good as 4000, all you can say is the lower the better. BTW don't get me wrong, I fully agree a 10 faced cylinder around the leg wouldn't look good just because it matches the SL avatar... Objects in SL, well most of them anyway, can be seen as stand alone items, not as avatar extensions, even when worn. Your objects do look awfully dense though, could you post close ups maybe? both in mesh view and rendered view...
  16. Maeve Balfour wrote: [...] Plus in this manner, you can have shadow effects WITHOUT needing individual prims dedicated for the effect (ala the old shadow prim concept from the "olden days" of building). So a big plus in PE savings as well. :matte-motes-smile: PLUS if the shadow texture is a dedicated one, rather than a shared texture... you can turn it off and on by script. When it's off you have two useless triangles, but that shouldn't be a big problem... There is one small catch though, adding a shadow plane to the mesh will make the object quite a bit larger in some cases, raising the LOD distances which is good, but also adding to the landimpact.
  17. Publik wrote: Yeah, and determining new weighting shouldn't be that hard...Something like: list linkset = //whateverinteger weight = 0;// loop through set{ if(linkset[index] == MESH) { weight += // weight of mesh }else // PRIM and MESH { weight += 1; }} Do sculpties calculate differently as well? Yes they could have left the "old" way of counting intact, even with a mesh in the linkset. That shouldn't be hard. The thing is I agree it's fair to do it the way they do it now, with SL prims represented by their actual weight. I also think they can't change the rules on old objects, so linksets with only prims still count as 1 erm... prim per prim. The combination of the two doesn't work though, as I said, it's an open invitation to put more pressure on the grid by linking everything under 1 prim equivalent to a mesh and everything over it to eachother. Maybe it's an idea to leave existing objects untouched and apply the new rules to new linksets. However this means most SL prims will become useless. A small torus for example would cost something like 100 prims. Maybe what they did is a first step in this direction, letting us see what old prims cost. The future will tell... @Drongle who said it's not a good idea to link sculpties and meshes.... It's not a good idea to even USE sculpties:)
  18. Yes typical how the Lindengods have done this, it's a great idea, primcost according to render/serverweight, but only if there's a mesh in the set. That's just asking for very very clumsy linksets...It does show you however how inefficient some prims really are, but I don't think it will do any good. People will link their boxes to meshes and the rest to eachother, only adding to the data traffic...... edit: or even worse people will unlink a set on a full parcel and they will find it in their inventory in pieces because the seperate parts cost more than the set...
  19. Oh as I said earlier we're on the same page alright, different paragraph maybe.... But one has to play the devil's advocate here and there to make a point or to keep things enjoyable hehe... very annoying your post was eaten, that happened to the first half of mine aswell yesterday...looking forward to your reply
  20. It's not that hard basically... if you link something simple like a standard box to a mesh it will cost less than one prim, if you link something with lots of faces like a torus to a mesh it will cost (a lot) more than one prim.
  21. There really is no answer to your question. If none of your vertices or faces are wasted, you did well, the amount is irrelevant. To me personally it looks good for that number, but that's just me:) A sculpt has 2048 triangles btw, so you're little over 1 if the 2500 is what you see in the upload window...
  22. I'm not sure, it could be a wrong texture channel....
  23. Drongle McMahon wrote: [...] This ca increase (or sometime decrease) the contribution of the ordinary prims to the linkset land impact. [...] Already working on the table for this Drongle?
  24. Chosen Few wrote: Maybe the best solution would be simply to limit the maximum total poly count that avatar can be wearing at any one time to a reasonable number. I'd define "reasonable" as something in the tens of thousands. Obviously, the billions that are allowed now are well beyond unreasonable, by any definition. If the limit were, say, 50K (which is still absurdly high for a realtime character model), that number could be divvied up any which way among all the attachments. They could all be in a single mesh, or it could be 1300 in each of 38 separately attached meshes, or whatever other combination the user wants, as long as the total stays under the cap. I agree, I really do, a limit would be good for performance. But I don't see from the top of my hat how one would implement that, given the fact we agree we are stuck with prims and their use won't be changed. Another simple calculation: the maximum number of attachment points is 38, with 255 prims each. The worst prim I can think of is a hollowed torus with a very small cut, within the first loop of faces. So we have 38 x 255 x (2 x 24 x 24 + 2 x 2 x 24) = 23 256 000 faces as a maximum pre-mesh, exluding the avatar. I'm not saying this is any good, but again, we're stuck with these numbers. There will be hell for LL if they'd ever dial this back. I'll assume people aren't wearing anything like this, but with a detailed pair of boots, some funky hair and a rediculous celtic collar worn, you'd be well over the 10s of 1000s of faces already. You wouldn't be able to add any mesh object to your av, but you could happily keep adding prim gloves, weapons, bracelets etc. This doesn't sound very fair to me. Personally I wouldn't mind if they did it, but lots of builders and buyers will be stuck with useless items. It's the same with scripts, I don't hear anything about the memory cap after all the moaning. (Not that I am looking for any news on that btw, so I could be wrong). Chosen Few wrote: Ideally, I'd really like to get away from measuring everything in terms of prims. It's arguable that there's still merit to that for builds, since land continues to be the metaphor for resource allocation in SL. But for avatar attachments, which have nothing to do with land, we can easily break away from that mindset. I'd much rather make it so people have to pay attention to the real principles involved with mesh management, rather than the artificial "prim equivalency", which really has nothing to do with anything at all. I agree on the first comment, although a "prim" is a concept people can understand, since they are familiar with it. Maybe "prim box equivalent" is a better term... or maybe the community needs to be educated and start thinking in polygons, quads, triangles, vertices etc. I don't know. I however don't see why you could compare meshes with prims when they are rezzed on land and not when worn. The prim equivalency is connected to the rendering cost (and other costs) afterall. Chosen Few wrote: I really don't think anyone should adopt the mindset that they're "allowed to push the system". Even if things didn't get any worse than they are now, the fact remains that SL still can't run reliably on a huge portion of the computers in every day use on this planet, and can't run at all on a great many of them. "Pushing the system" will only preserve that unfortunate status. Heyhey! I said push it "a bit". (This is wide open to interpretation ofcourse) All I ment was I don't think as a builder you should restrict yourself in such a way you would when building for a high end action game, where you really need to maximize performance to make the program function. Also in a game all objects need to match eachother. I think SL objects can have a high "look at me" factor, rather than blend in with the scenery. In SL there are lots of different "languagues" of building...mix 'n match. Everything within reason ofcourse (again very subjective), I didn't mean stress the servers and processors and graphic cards even more than is happening right now. The arrival of sculpts gave us the opportunity to make things look nicer (and save some "prims" here and there). The mesh gives us the ability to work more efficiently, but ALSO to make things look even better than sculpts. The way you are describing how you want mesh to work is one I can't share. It sounds like you want to make SL looking slightly worse with a huge performance gain. I'd rather see the mesh push the looks of SL to a new level with similair, yet slightly improved performance. We disagree, that's fine. (And no I am not on a high end gaming computer by any means, my buzzing black box is over 4 years old with a graphic card upgrade about a year ago) There are two things people can't stop complaining about: the first you already mentioned, that's bad performance, the other one is outdated looks. Both will never match up with professionally made programs, but both may be lifted a bit if you ask me. Chosen Few wrote: It's no different in a simulated world. Resources are still finite, even if imagination is infinite. The more of resources are used up in any one item, the worse off we all are, for all kinds of reasons. Therefore, we should all strive to use as few resources as is possible and practical, at all times, in all things. Hmmm, in most cases..yes. Don't forget in RL you can't put your car in your backpack and in SL you can. When resources are scarse people find ways..like in RL So if you only have 10 prims left on your parcel, you can sit on one chair on monday and replace it with a new one on tuesday. The same way of reasoning can be applied to performance resources. Anyway I think we agree on this, it's comparable to your "1300 faces per attachment point on average" suggestion. When you run low on resources in SL, you replace rather than add. Chosen Few wrote: As for the model itself, you could certainly do it with just two or three quads per section. Keep in mind that the avatar's neck will cover the inward facing surfaces, so those faces don't need to be there. The larger gauge upper and lower rings will do just fine with 6 quads per section, and they'd look great. Here's one I just made now, based very loosely on your picture. It's not nearly as well made as yours, since I only spent a few minutes on it, but that's obviously not the point. The point is it's just 1242 polygons. Had I been willing to put more time into it, it could be just as nicely built as yours, and still have the poly count of just two or three toruses, tops. Seeing it, three polys per section might work, although I'd add a backface. I think the 16 sections for a ring don't cut it though. Also You've skipped quite a lot of rings it seems... Anyway, your models proves what we both already knew. Mesh is far far more efficient than prims. (Your model is about 60 times lower in faces than the prim one?) I might redo this one at a certain point, but it's not on my todo list right now.... Chosen Few wrote: 24 sections is a lot for a half arch. All the objects people are used to defining as "round" in SL have 24 sections for a full circle. So, for a half circle, you only really need 12, and everyone looking at it will interpret it as perfectly rounded. That would save you nearly half your poly count right there. Since you say there will be a lot of these on the building, it's well worth doing. If you then make each section look like the lower of your two sketches instead of the upper, you'd save an additonal 96 polys. It would be slightly less texture efficient, but nothing that would necessarily cause you to have to jump to a larger texure size, so no real loss there. Also, the sections of the vertical pillars can obviously just be two tris per side. If you make them by extruding, you'll end up with eight tris on the underside of each section of the upper modling, and another eight on the top side of the base molding. Again, there's a slight loss of texture efficiency in using only two tris for each, but not enough to gripe about. Those faces are so small, they're not going to get many pixels, regardless. Here's how I'd do it: [PIC] Those are 422 polys each, including the wall sections. The arches themselves are 404 polys each. I didn't add the size just for the fun of it and the arch isn't half a circle. Where a circle has one focal point and an ellipse two, this one has three (I think the English term is surbased arch). That means there's a lot more curve in the ends. On the other hand a lot less in the centre. The fact the prim ring or cylinder has 24 sides doesn't mean this is what one should aim for I think. At the current size this would mean .5 meters per section, which in my opinion is too little for this particular arch, in this particular build, for its particular purpose. If this was a building block to go on sale as building block I might lower the number though. I used the 2 faces instead of 8 where possible, I think my second of the two sketches shows that I already grasped that idea. (Always a good thing to post these things, since everyone should be aware of these "tricks") One bottom is sloped, but it's 4 faces instead of 8 by lenghtening it into a pyramid. I don't think there's any room for improvement without changing the shape. I'm a bit confused on the polycount though (where I suspect your poly is a triangle, more confusion, people should talk in quads and tri's since they can both be polys, this includes me:)) My arch "as is" has 24x24=576 triangles (hey half a torus!) I don't see how yours has 404. I also don't see how you managed to build the rest out of 16 triangles. I guess by arch you mean everything except the walls..duh, nvm. If I replace all the sloped pieces by flat ones I would come up with 116 faces less, maybe that is a justified loss of detail or change of shape for that matter. my model wouldn't be 766, but 650 faces. I don't agree on the arch itself, not in this particular case:)
  25. I'm not 100% sure, but it is possible the hard lines of the box make the vertices double up...I'll have to try that when I have time. Anyway, 12 faces is the way it should be...you could test the very same thing but with a box with 4 polygons per side. If the hard lines cause the vertices to double up, that means it will have 48 vertices instead of 26 (I think).
×
×
  • Create New...