Kwakkelde Kwak

Ok, I'm getting confused now:) Hypothetical, if the memory of a sim is 128k... you can run 8 LSO scripts on it without the virtual memory being adressed, that's clear. but what happens if you run monoscripts using 4k each? Can you run 16 of them or 2 before things crawl to a halt? I'm not that educated on scripting, but common sense tells me the 4k of each mono script goes in the RAM. Then even if those script have 60k reserved, that reservation will not chip away from the RAM available. This would mean you can run 16 of them without using any virtual memory.

I'd say true then... The memory limit is not the amount of real memory actually used by the script, just the upper limit on it. thanks for linking that ...

PeterCanessa Oh wrote: Scripts compiled in LSO are always assigned 16k, scripts compiled in MONO are always assigned 64k unless it requests a lower limit (llSetMemoryLimit()). As far as i know the LSO scripts are assigned 16k and mono scripts are assigned 0-64k, not 64k. True or false?

Ok, thank you all for answering... I'll change my LSL scripts to mono then (with a limit) and see what happens. The original question really wasn't for my own scripts, but I'll poke the creator once more:)

Qie Niangao wrote: I'm not sure you're aware of the llSetMemoryLimit() function for Mono scripts. While that function does nothing to reduce the actual memory consumption (and uses some negligible amount of memory itself), it does reduce the amount of memory the script is shown to be using. I suspected that, but the creator (rightfully I think) refuses to add that code to the scripts since it only adds to the scriptload, even though the readings on it will show otherwise... anyway, thanks for confirming this. EDIT: Now this is a question for my own scripts... I was wondering if a mono script limited to 16k (or 15.9 for balancing out the function itself ) is always preferred over an LSL script.

I know I know:) I'm not that worried about lag, well not lag produced by me anyway. I am slightly worried though by being flagged as laggy even when I am not. Some avatars can be extremely scriptlaggy though, I've seen constant readings of 5.0 ms on a single avatar, that DOES worry me. So what I am really interested in is if these meters are useless when it comes to memoryreadings on monoscripts..

Yes for a proper monitoring I wouldn't rely on such a device, although it can be helpful. The thing is some people rezz these things in their store and the thing will show the numbers it reads together with the avatars name. So in many cases I am wrongfully flagged as laggy. Or at least I am pretty sure it is wrongfully. I always check my things before buying if possible and if not, I check after, both scripttimes and rendercosts. I have dismissed many items even though I really liked their looks or functions. Sometimes I use laggy items, but I try to keep it to a minimum, especially when going shopping...

There are a lot of worn and rezzed lag monitors around and I had a question about them. I use some items (not my own) that have a large amount of mono scripts in them, purposely set to mono for faster execution. The memory use, as I understand it, can be anything from 0 to 64k opposed to the set 16k for an LSL script. The lag monitors, again as I understand it, read the full 64k for the monoscripts instead of what they actually use. Using the estate tools I can see I produce little lag (script time anyway, around 0.3 ms usually), yet the monitors always show me as very laggy (in memory I guess). So my question is: Are the scripts reading the memory use poorly written or is it just a poor script command? Or am I overlooking something? Any information on the subject is welcome...

Although I agree on most things you say, very few of those things have a real impact on the graphics quality. I think, well in fact I'm pretty sure, the biggest problem with SL graphics is the same thing that makes SL great and sets it apart from other platforms. I'm not very familiar with realtime rendering besides SL, so forgive me if I make some incorrect assuptions in the numbers I use and feel free to correct me. Anyway, in a game the creator pretty much has full control over anything on screen at any given time. So the maximum of faces to be rendered can be set at let's say 500000. The main character can be 30k. Secondary characters can be a fraction of that, maybe 5k, buildings a lot less, plants are always very basic. In SL everyone can create their own items and usually looks are preferred over low data/rendering costs. This means the trees are made out of 5 sculpts with 10k faces, buildings have windowsills and hidden faces etc, secondary characters don't exist in SL and we all know most avatars with a nice collection of worn items won't be under 30k faces (or even close). Add to this the fact everything has to be streamed, server CPUs are shared and scriptload is very heavy compared to games and it is hardly a surprise the framerates are a lot lower than in a game built by professionals with full control. Ofcourse LL could improve some things here and there, but like I said the main issue is user built content and if they are restricting this, SL will soon be dead, since SL is SL because of it.

Medhue Simoni wrote: Who says that? Qarl doesn't say that. Qarl himself did actually, in his jira. How I missed the fact the project has changed since I don't know, especially since I watched the video from beginning to end when it was posted a couple of days ago. It looks like existing mesh (aswell as physics and custom avatars) will work with the deformer, you're right about that, my mistake. However... existing mesh wasn't optimised for the deformer, so the results may be poor. I haven't done any rigging myself, but I suspect the clothing made for the deformer would be quite different in shape than the stuff currently on sale. It would work, but in a similair way the SL skirt does and I think we can all agree that's not pretty...

I think the hardest part about that entire contest would be finding a good jury:) You have a lower display weight than I do, Chosen has no alpha glitches, someone else was superlow in costs because a square posts had 8 faces...etc.... I don't like contests btw:) But it was good fun to see how everyone jumped on it just to prove mesh is better than sculpt... even for landimpact...well in this case....

The old meshes won't respond to the new code, unfortunately, hence my fridge comment .... EDIT ...looks like the project has changed a bit, it will respond, but results may be poor (thanks Medhue for correcting me here)

hmmm you have the upload to the uploader then the upload from the uploader to the server...or something like that:) hard disk - server - viewer - server ? the initial upload has to be the full dae file I'd say.... Anyway, that's just once and shouldn't have any lasting impact on anything.. EDIT or is the upload to the uploader 100% local? in that case it feels very slow to me....

Carbon Philter wrote: In my admittedly rather precise world, scaffolding poles are tubular and I was trying to retain that look but so far I find that using 5 or 6 sided cylinders result in angles surfaces/ends. Maybe I have to accept reducing the appearance to achieve better values but With next to no detail in terms of texturing coming into the equation it's still a reluctant trade-off. My 0.3 display weight model had 6 sides. I'm sure you can squeeze in twice as many faces and still be at one prim. server and physics weight won't change. 12 sides makes a pretty believable cylinder. Carbon Philter wrote: In your various responses there's reference to Imposters and billboard as means of reducing the overall impact. Can someone explain, please - is that using a 2D image in place of the separate components at lower LOD? I can see difficulties there with alpha glitch if I have a lot close together. That's right, it's a flat plane with a picture on it. It often gives much better results than simplified geometry, at the fraction of the costs. As far as I have seen, the 2nd LOD model didn't pop until 90 meters or so away. I think alpha sorting issues are not very noticable from that distance... but there's only one way to find out ofcourse.

MaxTux Wonder wrote: Anyway, i did a full bug report on jira with all my experiences, and of course i'm not an expert of streaming, this is why i've opened the thread. i will not ask to lindens " how much data a mesh is compared to the vertice count when sent between peers." because i don't know what does it means. And I don't know if a 200kbs limit would stop a file 200kb big from passing through, I don't see why it would actually. And I don't know if the streaming limit is at all responsible for the problem you have. I know very little about this. MaxTux Wonder wrote: What's mesh for? There is no single answer to that question, but I agree, a big part of it so you can make your items look better. That does however not mean one should stretch the system just because they can. Mesh can be used for saving resource cost aswell, as you demonstrated yourself with the cube. It can be used for lots of things and there are lots of things to take in mind.... People don't have to agree, but it's good to see and hear various approaches in mesh building, with different goals and in different ways.

That video was posted here two days ago I think:) anyway, great news..does this mean we should all put our mesh buying urges in the fridge? .... Any idea when beta and the finished product are scheduled?

Interesting, I opened up a collada file and it looks like almost 2/3 of it is 7 digit normal data... Converting my 1.4.0 to 1.4.1 by exporting as fbx then turning it into a dae with autodesks converter does save some data, but 10-20%, not 67. Ofcourse converting to is not the same as exporting as. Also an identical file format doesn't mean the export process is the same. For SL it doesn't matter ofcourse, since that uses its own format. I guess I will just have issues with uploading models over 80000 faces, hmm I can live with that:)

MaxTux Wonder wrote: Yes high poly is the problem, how much poly is blocked by traffic shaping? How much polys i've to use to make it work right? Will work the same way with the all providers all over the world, or will solve just problems of few people? Those are questions that a really interested person in the topic should do. I don't want to sound whiny, but this is the first time you posted a direct question. I don't think LL has an answer to your question about different providers and their traffic shaping. There are so many different providers that do it. List of ISPs with traffic shaping You can ask a Linden how much data a mesh is compared to the vertice count when sent between peers. I do not think the forums are a good place for that, since the Lindens aren't very active. Maybe you could try support. MaxTux Wonder wrote: How much smaller i've to do it to make it works? You think i should try to do 10 different versions of the avie each one with a different poly count? You know that a full avie take a month of hard work 8 hours at day? And if this fix will work only for me and not for other users? Until i don't get more informations from users and from Lindens, i can't do nothing than wasting time and money. One could try with very basic shapes, like I did with a plane. That takes more time to upload than build and export to dae. There is no need to make 10 versions of an avatar that took a month to build. Just 10 planes would be fine to give a general idea of what the limit is, well at least for the person testing. Now that you've changed ISP you can't do that anymore ofcourse:) MaxTux Wonder wrote: You of course don't have any idea of what it means to work on computer graphic. Should i follow suggestions from a builder wannabe, that doesn't even knows that 40k+ it's under average polycount for an avatar in SL? I don't want to stick my head into a bees nest, but Chosen knows perfectly well how things work, years of forum activity back that up. I've seen Chosen rebuild objects that had issues in minutes where it would have taken me hours and I am pretty experienced myself. I've seen the robot in this thread, which looks pretty impressive, even with the polycount being too high. I can't speak for anyone else, but when Chosen claims something it's usually spot on.

Should I post a 23 MB textfile here so you can have a look? My dae exports are 1.4.0, but the difference in filesize is really big....

I tried with a 255x255 plane, right at the limit of 65536, that didn't upload. The dae file was 22 MB and took a long time to load, then it crashed with a time out warning in the log. So I tried the above, just to show it is possible to have more than 65k faces. (the file was 13MB) I have succeeded in uploading bigger models in the past... I wouldn't even think of putting them on sale though...

I tried aswell, the wiki is right...

MaxTux Wonder wrote: I don't think i can do worse than boots for 229400 faces like i posted up. (greats boots anyway, love it) Anyway the limits are about triangles, you can't use 65k vertices on meshes, will just not upload. From the wiki: There is not a maximum # of triangles a model can have, however the number of vertices is limited to 65,536. Second Life wiki On these forums we figured out with mesh you certainly CAN do worse with mesh than with sculpts. In theory you can wear around a billion faces with mesh, with sculpts "only" 17 million. Not saying that you should:) And please don't get worked up over Chosen's posts. Chosen can sometimes sound like a broken record, but that's because a lot of issues have the same reason, if anyone is a positive contributor to these creation forums it has to be Chosen. People will read your original post first, the one with the link to the jira. I don't think there is anything that can be said on the forums about it, so in my opinion it doesn't matter in which direction the thread spins. Neither do I think it's an issue SL should give priority. As has been replied to your jira, it's an issue with the ISP. Yes LL could make changes so the problem is less likely to occur, but so can creators.

You can do far worse than 65k triangles... you can use 65k vertices. Not that you would be doing the grid or anyone on it any favours though...

Since the entire forum is building scaffolding, I made one aswell... and ofcourse the mesh has to look better:) so I went with 6 sided posts. at 11x10 meters LOD medium doesn't kick in for a good 90 meters (Object detail maxed out, RenderVolume at 2.0), so I'd say it's safe to use the imposter for all levels except high. Download weight: 0.3 Physics weight: 0.4 (didn't make a model) Server weight: 0.5 Display weight: 636 (because of the alpha on the imposter, only geometry would have been 289) I think it's fair to say the mesh beats the sculpt on all levels. It took minutes to build, where a sculpt takes a lot longer to pinch, squish and fold everything. You can link 2 of them together for the same landimpact as a sculpt. Display weight is a lot lower than the 2400 (?) for a sculpted version. It looks better, at any distance (that is if the posts were 4 sided, which I think they were)

Kavorka wrote: is it possible to have a seperate texture for the imposters? Yes that's possible, there's one small catch though. In all models you need to have the exact same materials, so this means you need to add (at least) a single triangle with the material for the imposter in your highest LOD model and a single triangle with the high LOD material in your lower LOD model. Kavorka wrote: I'm using OpenSim for the project, so the "cost" of uploading doesnt matter and as far as I know, the PE is irrelevant. All I really care about is the polycount. In that case I would never use a sculpt again. In 99% of the cases you can build a mesh that looks just as good for less triangles. The remaining 1% will be the same. A sculpt will never be more efficient as far as polycount goes. Polycount, PE (or LI these days) and cost are closely related btw, for mesh objects anyway.