Sure, a mesh chair is a good example. Thr visible chair can have hundreds, even thousands of triangles in a small area. It may not be necessary to make them completely phantom however. Using a simple cantilever shape for a collision mesh could provide semi-realistic collisions for many cases and probably would not require much work from the CPU. Such a shape could be uploaded along with the chair mesh.
It's probably also worth considering that the goal of the OSCC regions was to accommodate 100 avatars reliably in a single region, so any measures that were taken to eliminate any unnecessary CPU overhead likely had a strong influence on reliability. On Sat, Dec 6, 2014 at 3:21 PM, Mister Blue <[email protected]> wrote: > For BulletSim, collisions between terrain, spheres, and boxes is an easy > computation. Collisions with meshes is a lot more computation. For > instance, the OSCC conference has a whole bunch of high resolution (large > mesh) chairs. The CPU to compute collisions with them was noticeable. In > that case, all the chairs were set phantom to save CPU time. > > In general, avatars on terrain or blocked structures should not create > noticeable overhead. When you add meshes, you might have to consider > phantoming some things. > > -- mb > > On Fri, Dec 5, 2014 at 1:32 PM, Dr Ramesh Ramloll <[email protected]> > wrote: > >> Thanks Dahlia :) >> >> On Fri, Dec 5, 2014 at 4:05 PM, Dahlia Trimble <[email protected]> >> wrote: >> >>> A lot depends on where the "physical" (moving, rigid objects or avatars) >>> are relative to the static (non-movable) non-phantom objects. Collision >>> testing can be a significant part of simulation load. It generally happens >>> in multiple phases: a "broad phase" where any moving objects' sizes and >>> positions are compared to other objects to see if they are close enough to >>> warrant more precise testing, and a "narrow phase" where any potentially >>> colliding surfaces are tested. If your scene is set up so that you have >>> many complex collidable (non-phantom) static objects but all of your >>> avatars are not near them then collision testing load should be fairly low. >>> However if they are all standing on colidable objects made of hundreds of >>> small prims then collision testing load will be much higher. Some prims >>> and/or mesh models can have thousands of triangles which could each be >>> subject to collision testing. >>> >>> In general if you have very complex objects it's probably better to make >>> them phantom and superimpose a simpler, invisible shape which can be used >>> for collisions. The mesh uploader in most viewers offers an optional >>> "physics mesh" which could be used for this purpose as well. However, if >>> simulation CPU load is not an issue for you then you could probably get >>> away with ignoring such optimizations although considering how content is >>> often repurposed it could be considered a best practice to use them. >>> >>> On Fri, Dec 5, 2014 at 12:16 PM, Dr Ramesh Ramloll <[email protected]> >>> wrote: >>> >>>> Hello there, >>>> As I was reading about opensim performance on the opensimulator.org >>>> site, I came across these two recommendations >>>> >>>> - Make as many objects phantom as possible. Phantom objects do not >>>> need to be tested for collisions with avatars and other objects, >>>> reducing >>>> physics frame time and increasing performance. >>>> - Make as few objects subject to physics (e.g. falling under >>>> gravity, movable by other avatars) as possible. Physics objects need a >>>> lot >>>> more collision testing than ordinary non-phantom objects. >>>> >>>> >>>> I understand these appear fairly logical. I am curious though, are >>>> these differences really going to make perceptible improvements in user >>>> experiences? Are there any metrics that would say help us know when to >>>> start converting unnecessarily physical objects to phantom? >>>> Thanks >>>> Ramesh >>>> -- >>>> 'Consider how the lilies grow. They do not labor or spin.' >>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research >>>> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: >>>> 208-240-0040 >>>> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore LLC >>>> <http://www.deepsemaphore.com>, RezMela <http://www.rezmela.com>, Google+ >>>> profile <https://plus.google.com/103652369558830540272/about> >>>> >>>> _______________________________________________ >>>> Opensim-users mailing list >>>> [email protected] >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users >>>> >>>> >>> >>> _______________________________________________ >>> Opensim-users mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users >>> >>> >> >> >> -- >> 'Consider how the lilies grow. They do not labor or spin.' >> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research >> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: >> 208-240-0040 >> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore LLC >> <http://www.deepsemaphore.com>, RezMela <http://www.rezmela.com>, Google+ >> profile <https://plus.google.com/103652369558830540272/about> >> >> _______________________________________________ >> Opensim-users mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users >> >> > > _______________________________________________ > Opensim-users mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users > >
_______________________________________________ Opensim-users mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
