United3dArtists Archive

I heard something about a limitation of 5 Mega per scene, so this is a problem because how can we set up wonderful meting rooms if the TV already explode the limit?
Can we improve it, it's too expensive?

I just want to make it better, I'm not disregarding it, I love it!

Cya

It's ok, don't worry! : )

That artificial 5 Meg Scene Limit was imposed by Caligari because they were concerned that their Customers would have a hard time navigating shared space scenes larger than that IF they were on Dial-Up Modem connections.... it was never imposed as an absolute limitation on what is possible in trueServe online scenes offered OUTSIDE Caligari's on non-Caligari servers.

Even at Caligari on their own servers, Jason and I and others would occasionally load scenes ontto the Cali trueServe Servers which were between 5 and 12 meg, and we had 5 to 17 people in those scenes at the same time. That was no problem for those with high-speed Cable Modem connections at all, but it was a bit rough on those with broadband connections, they would lag a lot if they moved around, and it was brutal on those with Dial-Up, often causing them to lag so bad that they lost connection or gave up trying to wait for the lag to subside.

You CAN have scenes over 5 meg in total size, just bear in mind when you do that some people will have trouble navigating them if they have very old or obsolete connection hardware or service provider lines.

You would be amazed at how awesome a scene you can make with less than 5 meg of total object weight though, we had scenes that looked like they were 20 meg but were under 5, in fact most of our scenes wound up like that online.

Whoever hosts a trueServe environment online needs to keep constant tabs on who is uploading content there and what the current scene size is, or they need to assign someone to do that for them. There is also the issue that people can potentially upload a huge picture (over 800x600 pixels) and that may not even show inside the scene yet have so much weight that it causes slower connected users to drop out of the scene. Such objects DO show up in the LE (Link Editor) but noticing them when they do and deleting them immediately is a responsibility that is important, one we should all pay attention to in the LE on behalf of the Host.

Relax though... in the weeks ahead, we will show you how to make breathtaking scenes that are deeply interactive and immersive WITHOUT exceeding 5 meg per scene!

yep; it's just a matter of 'efficient design'. I need practice in that area, that's for sure.

Also, we can have 200 meg of scene files, you just need to set teleporters between the scenes or a linkbar and have each scene be 5 meg or so : )

Many Thanks 3DVD for the great explanation! I need to learn now some tips to do good and less than 5 mega scenes

Thanks

There are really lots of creative ways around the 5 to 6 meg practical scene limit, for instance...

you can have a door at the end of a scene in a building wall or a freestanding gate, and when someone clicks it or walks through it they are transported to the next portal scene which is also 5 to 6 meg ans seems like part of the first scene!

I am going to have to investigate this, I like the portal option of handling scene load with a fast connection. For a slow connection there will be delay from one to the next. The level of detail system I was thinking about I don't think will work in OurSpace but should work with file to client type scenario. So larger scenes are possible and I really hope so. There are other things that may help speed up a larger scene, one is shared materials, other is merging geometry. Shared materials and merging geometry cuts down on cpu calls to display objects.

So much to explore in this, TrueServe for me was really the ice breaker. I havn't set up trueServe yet but should be in the very near future.

noko wrote:I am going to have to investigate this, I like the portal option of handling scene load with a fast connection. For a slow connection there will be delay from one to the next. The level of detail system I was thinking about I don't think will work in OurSpace but should work with file to client type scenario. So larger scenes are possible and I really hope so. There are other things that may help speed up a larger scene, one is shared materials, other is merging geometry. Shared materials and merging geometry cuts down on cpu calls to display objects.

So much to explore in this, TrueServe for me was really the ice breaker. I havn't set up trueServe yet but should be in the very near future.

Agreed. The file-to-client scenerio and all it entails, including (for trueServe) unprecedented specific focused development on that particular aspect, will be necessary and vital in the times ahead. I am confident we will make (rather than simply find) ways to increase the general scene sizes without having slower line speed user drop. It's going to be increasingly important to a growing number of us as more and more of us fire up our own new trueServe hosts, so the necessity will give birth to the invention I'm sure.

remember there is also the caching system , so static objects can be part of a cache when they are in a finalized state.

the other thing that is now possible in theory , is using scripts and making calls to serverside libraries , it was planned to have more flexible server library system , but it didnt get fully implemented and should be approached with caution in mind.

however now that the server is in your hands , there is as far as theory goes it should be possible to , use scripts to load objects from a server library and place them into a scene on demand , -- remove them from the scene when not needed , etc ..

some things to be aware of .. (theoreticaly as I never tried this out) if multiple clients are in the scene and objects are triggered to load by proximity then caution may be needed so that not too many objects are loaded by too many people all in different areas of a scene at the same time, or a method on delegating which client gets the downloaded object so that not all clients get the same object , especially if they arent looking at it or near it. Downside of delegating which client sees what is that it sort of takes away the aspect of each person seeing the same objects but from a slightly different view point and unless it was a massive area then it defeats the purpose of a close community adventure , after all the rooms are what can create the confines and atmosphere that close social gathering groups seem to enjoy.

scripts and loading ( if the objects could be encrypted so not copied/saved to clients libraries) would work good for a store with low detail proxies or 3d buttons that can be clicked on to load a higher detail model/object for inspection from a server library then a script to remove it from the space after viewing.

Hey Cayenne, good to see you here!

Not familar with caching system, is there anything special one has to do for the cache? I take it the cache is on clients local machine, is that right?

Yes that was the LOD I was thinking about using scripts to reduce high polygon meshes with simple meshes using mesh input attribute on objects using triggers. I can see now that wouldn't work to well in OurSpace with a number of folks tripping a whole bunch of triggers. Do see it working for a single user though. Good feature that objects can be loaded from server via script. Wonder if these objects can be pre cache on client machine in the background?

good to see you here too noko ,cacheing is performed via command by admin in the space using truespace or it should work if the command is performed on the server for selected object or objects. ommand is in the manual
what this does is it generates a unique cache_id number for an object.
when a client visits this object is placed into a temp folder on thier hardrive usually in thier users temp **rosetta** dir .(need to check exact name)
when they next visit a space the server checks the client to see if it has matching cached objects prior to loading the scene , if they exist , it uses them from the cached folder , if they dont exist it sends them new from the server.

Sometimes however if an object is changed on the server , the client can end up seeing a different version of the cached object, it could depend on when they visited and what version of the object was there when the cache id was generated , so rule of thumb when changing objects is either to give them a new name and generate a new cacheid or remove the cacheid and then replace or manipulate the static object then regenerate a new cacheid for it.

If you want to see if objects have a cache id then you can hold down the alt key when opening the scene view , either in the server UI or if logged in via tS and are managing the scene.

With the scripted loading of objects from a server library it should be very possible but it hasnt been tried , at least by me with this latest version ,although I was getting close to attempting to test it out prior to [END of Business], on some earlier server versions I did do some tests by loading and running some rsrec recordings ,it worked but again caution, remember the objects inside the recording sort of needs to exist prior to a recording happening , but its possible to build a recording with preplanned scripting already set before the recording begins.(gobbledy gook but i'm sure you'll understand this)

So, if cacheing is not implemented, then this could very well cause increased delays for some clients?
Leon is having issues when logging in; perhaps this is the problem.

I have not yet executed the cacheing command.

Perhaps that is the most important item on my Hit List now.

I'm not sure, I'll do some tests tomorrow, to see... But I think is a problem at my side (client) not of the server. Anyway it's interesting...

Cya

froo wrote:So, if cacheing is not implemented, then this could very well cause increased delays for some clients?
Leon is having issues when logging in; perhaps this is the problem.

I have not yet executed the cacheing command.

Perhaps that is the most important item on my Hit List now.

Caching will help, but so will turning off the Modelside Bridge or using truePlay. It could well be Leon has the Bridge on, and you know the effect that has online.

Also Leon is acessing the server from South America, I dunno if that has an effect too.

Another factor is huge libraries open, if someone coming online has a huge library and the stack has all those folders open, that doesn't help either.

Another factor could be how many views are open, 4 way or one main window.

Lots off factors come into play, the Bridge though and unnecessary libraries open are the first culprits I suspect that slow stuff down.

Two years ago I had so many files in my Libraries from all the dev work we were all doing, that I had to take and split the libraries off into 2 gig worth of Libraries NOT in the trueSpace install folder tree and import from there. That speeded up my trueSpace by about 400 percent offline, let alone online!

hm interesting; I did not know libraries in the stack on one's trueSpace install would cause
problems like that, when they login. Is that what you're saying Mark? Hm.
So, if a user closes all their libraries, then lag time will improve for everyone?

froo wrote:hm interesting; I did not know libraries in the stack on one's trueSpace install would cause
problems like that, when they login. Is that what you're saying Mark? Hm.
So, if a user closes all their libraries, then lag time will improve for everyone?

Oh no, it will improve for the individual with the large heavy stack libraries open, but it is a clientside memory issue, the quantity and size of the libraries open by others has no effect on the rest of the people in the same room at all.

Oh Ok. Thanks. That makes more sense.

Leon... check your Windows Recycle Bin often and keep it cleared... trueSpace dumps all deleted files in there and that slows down Windows a lot.