scripted prims vs non-scripted

Would this work? It seems to me as far as CPU time goes, scripted prims use the most, whereas non-scripted non-physics enabled prims use the least. This method would give builders more prims to build with.

Scripted prims: 2
non-scripted physical prims: 1
non-scripted non-physical prims: 1/2

One bump!

NOOOOOOOO!!!

And in case you didnt get that:

NOOOOOOOOOOOOO!!!

Interactlvity is the *Main Goal* of SL. If you 'tax' people that use scripts, ALOT of the demand for interactivity will dimisinish, in the worst case totally die out.

Scripts dont tax simulator usage *that* much, unless you factor in physics. THe real reason things seem slower with scripts enabled is that very reason. Havok 2.x will solve this problem for us.

==Chris

I don't know. The reality of it all is most scripts don't effect sim performance at all. Buttons and switches, doors, lights etc. Most scripts run for a very short time and don't effect performance much if at all while they do. There are exceptions of course, but a hollow cut tori costs the same as a cube. Scripts are what make the world interactive and interesting and should not be limited at all.

Since this is such an awful idea its probably not worth mentioning that most scripts just occupy one prim in a linked set.

I'll perform a duet with you on that one, Christopher.

Although, I would be all for the increasing the allocation for physics (although I always was wishing there was a sim with very limited physics (i.e. enough to prevent the AV's from falling through the ground) and allowing more primes and more script power.

do scripts and particle effects count as prims? what about textures belonging to an object?

is that three questions?

does that make it four?

Just trying to think of ways to make people with "prim heavy" builds happy. Since buildings usually have physics disabled, and hence can't move, you'd think they place less strain on the server. Therefore you should be allowed more of these prims.

In the current model you could have 15,000 scripted prims in a sim and the sim would probably be overloaded. If you put 15,000 stationary prims the server would probably not be overloaded. Maybe it could support 20,000 prims. So in the current model there are wasted server resources.

I'm obviously not a Linden. I'm just guessing how this thing works. Its my presumption that when the physics flag is not on, the sim skips over that prim when doing physics calculations. Physics is an expensive operation involving floating point arthimetic, so it seems logical that non-physics enabled prims use less resources.

Would the reactions have been different if I had stated it this way?
Scripted prims: 1
non-scripted physical prims: .9
non-scripted non-physical prims: .75

This way nobody loses any prims. You can only GAIN prims by going easy on the scripting and physics. That seems pretty WIN-WIN to me.

Ah - I think we may have missed a trick here...

I seem to recall (feel free to correct me if otherwise) that in the whole palava over "1.2 changing prim limits which means havok 2 will raise them again - woooo", the point was made that havok 2 will not raise the prim limit per sim, and that limit was primarily due to the streaming of data to the client, not apparent server load.

Additionally, I think it's stated that scripts run on a timeslice basis on the server, so that it always has its time to do the general data stream and physics work without overly affecting performace - in theory if you pack a sim full of scripts, the scripts will get slower due to fewer timeslices per second, but the overall user/physics FPS stays the same.

The thing which really seems to take the time is physics calculations, as can be seen by the famous "interlinked physical cut hollowed tori ohmygod I'm swimming in treacle" experiment where the server _does_ appreaciably bog down.

Anyway - tax on scripts per prim, and physics scripts - baaaad.

Besides, if it was going to make a difference, wouldn't it have been tried/discussed already?

I apologise if this post didn't actually get to a point, or if it did and it wasn't the one I intended - sorry. I'ts now quarter to four am, and I'm going to bed.

Merry Christmas...

Nope, nope and nope.




Your model is slightly incorrect. When a sim has 'too many' scripts, its the scripts themselves that slow down, not the sim. The sim only dedicates a few CPU cycles to scripts, the rest is dedicated to other purposes.

I still dont like the differentiation between scripted and non-scripted objects, it really lowers demand of any kind of full scale interaction implimentation.

==Chris

Ok, forget I ever mentioned scripts! See how flexible I am!

If physics vs. non-physics were assigned different "prim weights" could this allow large scale builders more prims without degrading server performance? (I'm guessing only Lindens know!)

If this is true then I thank you all for the lively debate!

I heard that the prim limit is set according to framerates people get. As soon as the average frame rate can be brought up significantly then the prim count can be brought up. That was a big part in why prim limits rose 50% alread - 1.2 worked a LOT on improving frame rates.

One key point I think you are already trying to steer away from is that physics takes a LOT more server resources than scripts. A lot. I mean, a whole really extremely lot. The scripts that take a lot of resources do so because they mess with physics - its the physics that mess it up not the script. Well 99 cases out of 100 that is.


Chris is right about scripts only slowing down other scripts - unless they deal with heavy physics. Again though it is the physics that slow the sim down, not the script.

you're right about the framerate ama. the sim hosts might be perfectly capable of supporting seven-million prims if it's only a matter of calcuating. the outbound pipelines and our average cards' ability to render in real time are the bottlenecks.

there's no point in ll paying to increase their bandwidth until we all have nivida quantum 90,000s with 4gb of memory. spend your christmas money wisely.