Da5id Weatherwax

It's getting there... At this point the todo list is all code - which is a huge relief. What it can do so far: accurately rez all its "helper objects" irrespective of its own position and orientation. Correctly rez out a full set of physical balls for the start of a game accurately enough that the ones that should be touching do but don't overlap and collide forcing them into motion. detect if a "color spot" is impeded by any other ball and do the math for correct respotting of the ball if it is (use the first free higher-value color spot, or if none of them are free, as close as possible to its proper spot along a line down the table) irrespective of the table's inworld rotation. accept commands from the HUD to make aimed shots at controllable strength. The ball scripts are still hitting glitches with adjusting between sliding and rolling friction. I suspect they are mostly to do with the script engine and Havok cycling at different (and unpredictably different) rates so what can happen is that what my script and Havok think is "current state" can be slightly out of sync with occasionally silly results. However, I'll continue to artificially create as many stupid edge cases as I can come up with and will just put together the most efficient way to trap most of them that I can come up with. Ah well, if it were ever going to perfect, it wouldn't be code.

Physics material settings seems somehow majorly busted. I can set specific physics characteristics (restitution, friction, density - and gravity but I leave this at default 1.0) on a "one prim" object using llSetPhysicsMaterial. I can set either a single "prim" or individual members of a linkset to one of the presets ("wood", "rubber", "stone" etc - which modify all the same values except gravity) either in the editor or via a script by using the PRIM_MATERIAL option in a llSetPrimitiveParams() or its various analogs. Using llSetPhysicsMaterial to try and get more specific in a linkset throws an error. Trying to use the inworld editor to change these parameters on an individual prim of a linkset silently fails. (and the values reported in the inworld editor for these values is not modified by changing the preset either.) So... I can set realistic physics properties on a billiard ball - and them bouncing off each other is now looking really "right", and it's a nice validation of the mass calculations that when I feed it a density number that I calculated from real-world parameters of a billiard ball it gives me a calculated mass for a real-sized sphere that matches reality to within the tolerances for match balls - but for the rails I'm stuck with the "rubber" preset and there really isn't a good preset for the table bed. But on the positive side I can report that my earlier math was correct and so was my suspicion of the "centerline issue" - given a max speed of 12 meters/second a physics prim has to be 0.52 meters thick to pre-empt any possibility of collision crash-through.

Ok, I will Initial positive results testing with invisible physics prims forming the collision surfaces of the cushions. It's something of a "good news, bad news" situation. The good news: Between the physics changes and some mesh geometry tweaks I've been able to hold the WIP LI down to 15. Even allowing that I still need to add some "detector prims" for functional reasons, that's still "within budget." The bad news is that with the closest approximation I have managed so far it's proving surprisingly awkward to model an accurate pocket profile even though it should be possible with just a pair of cylinders on each side. However, math to the rescue! I've spent the last few minutes solving the equations of cylindric sections to come up with hard numbers to give an exact set of cylinder prim dimensions and positions that should provide the most accurate result possible within the SL coordinate space. employing only stretches and rotations to the cylinders, no twisting to bring back the collision gaps Next time I'm on the beta grid I'll be bashing out a quick script to implement those numbers and create a 4-cylinder "pocket profile" linkset as precisely as possible and will then build them into the table in place of my current approximations. While I was messing with the math anyway I took the time to address the known issue of physical objects crashing through others and not colliding. As I understand it this occurs when the collision takes place entirely between physics frames, with an object passing completely through another between "ticks" and the physics engine therefore never knowing a collision took place. Assuming that this is correct and knowing that the physics engine cycles at 45 frames/sec at zero time dilation, all I need is a known maximum speed of any ball to determine how thick the physics prims need to be to prevent this happening. For the maximum speed of any ball, that would be the same as the maximum initial speed of the cue ball - every other ball that moves in the shot will move slower than this. Based on the info I've so far discovered, a reasonable number for this would be around 26mph. Interestingly enough, the 45 frames/sec of the physics engine and the conversion factors between mph and m/sec almost exactly cancel out, so at 26mph (just under 12m/sec) an object will travel 26cm in SL coordinates between physics frames. Taking a simplistic view, therefore, it would appear that if the physics prims are a minimum of 26cm thick, balls will not crash through at the velocities involved in playing the game. I am not convinced this simplistic view is adequate, however, since if the center of the ball has passed the centerline of the physics prim before Havok "realizes" a collision is underway I can easily see that Havok might bounce it off the "wrong side" unless this case is explicitly trapped in the Havok code. Since I can't look at the Havok code to be certain, I will test at both 26cm and 52cm thickness, building a test rig to fire physical billiard balls at a collision surface at 12m/sec and making sure that they do not penetrate at the highest speed a ball could achieve in realistic play.

Actually it works surprisingly well - at least from the basic testing I've done on the beta grid. The triangle of reds breaks pretty much as I'd expect - at least from a solid collision - and they subsequently bounce off each other in predictable, and therefore codable-to-be-at-least-an-approximation-of-realistic, ways. The balls on the table in the gif above weren't placed there, they all got to their positions from me grabbing balls with the cursor and rolling them into each other starting with 22 balls racked up for the beginning of a frame and me flinging the cue ball down from behind the baulk line. They have tended to be concentrated around the peripheries of the table because the cushions need a slightly higher coefficient of restitution than in the table version I used for that image. More detailed testing, in particular thinner impacts, will require me to finish the code for the cueing HUD and finalizing the comms protocols between the games various components, so I can aim more precisely than simply cursor-grabbing the cueball will allow... but it's going to happen Don't get me wrong, I know Havok has limits and the API LSL gives us into it imposes even more.. I am deliberately trying to push those limits with this and see how far they can go before squeaking

Well, the walk itself is actually less than 2 minutes, since the club is literally at the end of my street - but I did have half a glass of single malts worth of contemplation time in addition to the walk, and - as I'm sure you're aware - such things are not to be approached with unseemly haste, particularly not in Scotland

You're absolutely correct, and I started this project after playing a couple of frames down at my local club and between savoring the aftertaste of the glass of single malt I rewarded myself with for playing rather well (for me, at least) and strolling home I found myself wondering just how realistic a table could be made using native Havok physics for its mechanics. There's three different "collision surfaces" I'll need to take account of. The table bed will need to collide almost inelastically and have an artificially low friction as I've already determined in testing that Havok doesn't do rolling momentum very well. The balls will have a very high coefficient of restitution as collisions between billiard balls are almost perfectly elastic - there have been several articles published on the physics of a billiard table and I have reliable numbers for their real-world collisions and their other physical properties. The starting point for the cushions will be SL's default "rubber" properties. However, those are just the starting points. What I HAVE determined is that - at least with triangle based physics meshes, I haven't resumed testing with prims providing the collision surface yet - the collision angles work as close to correctly as can be determined by eye alone, exerting a rebounding force correctly along the normals of the surfaces in contact. With the above starting points, once the table shape is working correctly, the next step is empirical testing making incremental adjustments to the physics properties of those three components using llSetPhysicsMaterial calls until each component behaves as close to "correctly" as I can achieve. Where I know I'm going to have to "cheat" is with application of spin to the cue ball. At this time I've worked out the math for an approximation of it that will allow a measure of cue ball control during collisions but will not allow things like swerve shots or impart spin to the object ball. I'll be testing that more thoroughly later in the process and may be able to refine it beyond that point but that alone would be enough to bring a level of realism to the table's play. The other thing will be to avoid balls leaving the table. Under most collisions and impulses the game will impart there should not be an appreciable z component to any force applied but "should not" and "will not" are very separate things so there will be code in the balls scripts to clamp the z component of their velocity to zero.

FWIW - here's where it's at.. and its incredibly vram-efficient, because in its current version it uses just ONE 256x512 texture for the markings on the table bed - everything else is blank textures/flat colors and advanced lighting. LI14 before I add physics prims and that's mostly physics weight for the tri-based rails, so it will go down before it goes up... I did this ani-gif to validate the minimalist texturing approach and it does work...

7 cubes and 24 cylinders because each rail will need a cube (for the long bit)and 2 cylinders at either end (the two parts of each compound radius overlapped so they meet at a common tangent), plus, yes, one for the table bed. I was originally thinking I'd need cylindrical "detector prims" at each color spot to detect if it was unobstructed when respotting the balls but I've solved that by allowing the table to poll the ball positions and do the relevant vector math instead. I'll still need invisible detectors in the pockets to order the balls to die when potted but those are already figured into my prim budget.(yes, I wrote most of the scripts before laying down a single vertex)

fair enough - I'll give it a shot and see how bad it gets. Project (provisionally) UNjunked because I want this table playable rather than just looking pretty

Solution 1 would work for a pool table, since the cushions of a pool table take a straight cut into the pockets. However, for a snooker/billiards table the cushions curve into the pockets with a two-step compound radius. Those curves are easy to model with relatively few vertices but they mean that the cushions must be modeled invidually, because doing them as a single piece on a full size 12-foot table causes the uploader to label the tris making up those curves as degenerate. By uploading them separately, then the tris making up these curves are relatively "larger" as a proportion of the overall model size and are no longer considered degenerate. Yes, I have tested this, because that's how I originally WANTED to model them. Solution 2 can be done, but would more than double the LI of the table as it would add a minimum of 18 extra prims, or 30 extra if the compound curves are accurately reflected in the physics prims.Given that to rez enough physical balls to play a game of snooker requires 22 on top of the tables LI requirement, having the table needing 50+ LI to rez before we even start thinking about the balls is enough to render the project non-viable.

That's what's doing it. There's no way in Hades the cushion and rail on a snooker table is EVER going to be half a bloody meter thick, as that's 7 or 8 times the to-scale dimensions of its cross-section. Since this is "by design", project junked.

I'm aware of that - the notes on the removal of the gap were that it was removed for objects without any concavity, and in this case neither the visible mesh nor the physics mesh (and yes, it is triangle based) have any concavity. I can approximate the shape I want with invisible prims and just set the mesh as physics:none but that would be extremely suboptimal as it would add substantially to the LI and would only be an approximation - the angle of the surface normals is a factor in how the objects should collide and the direction they bounce. Sadly, coping with a 5cm gap by playing tricks with the physics geometry is not an option, because trying to do that would break the bounce angle worse than approximating it with prims.

What the heck do I need to do to make a physical prim actually rest on the SURFACE of a mesh? The mesh in question is entirely convex, set to physics:prim and its physics shape matches its surface geometry. But if I drop a physical ball on the flat upper surface of the mesh it bounces and hovers some distance above it. If I approximate the same shape out of prims the physical ball drops and rests on the surface of the object. Is the physics engine assuming that "meshes count as having concavities" even when they don't and imposing the wider collision tolerance of that scenario? If it is, I'd call that a bug...

It's pretty easy to rotate around an arbitrary set of coordinates without fussing with balance triangles.. you just multiply the vector from this rotation center to your objects base position by the rotation to get the vector to its post-rotation center and update both its position and rotation in the same call to one of the SetPrimitiveParams group of functions. Since this has been something we've been able to do from day one, using balance triangles is just sloppy work, an unnecessary kludge.

Not my curcus, not my monkeys. You or anyone else want to help a ripper rip, that''s your problem. Me, I wont.

Well you damn well noticed it now. I make all my own meshes from scratch,I make all my own scripts and anims, and if I cant match the quality of a decent mocap house I still get as close as I can, What I sell is what I MADE. Rippers from other games are scum, they take the work of other artists and claim it as their own. That's bogus and actionable.I may not ber the best creator in SL but I AM a CREATOR - I make everything I sell. Folks that sell ripped objects are scum. Period.

Alpha fighting? Is any part of your mesh "wearing" a texture with an alpha layer and set to alpha blending? No, scatch that, you said no alphas. IS it possible your underwater mesh(es) are being culled because they are totally obscured by a "brighter" water surface?

You've said you;re trying to convert ripped models from another platform. What possible reason would real creators, folks who have suffered the depradations of your kind, have to assist you in ripping off one of their colleagues and in the process violate the LL ToS? Once you admitted that you were ripping auto models from GTA4 and similar titles, you became a pariah. NOBODY can help you without breaking the law and the ToS themselves. We can;t stop you but we are OBLIGATED not to help you. Sooner or later you'll have a much bigger problem, and that will be LL revoking your right to upload mesh at all.

Medhue Simoni wrote: Here is a little inspiration for you guys at the Lab. HOLY... That rig is some mindblowing work. If we could do that in SL I'd be happy and sad. Happy because it was available and sad because I'd be totally unable to compete

Please.. PLEASE, make the prims on your hair creations mod perm! Those of us that occasionally wear hats with your lovely creations need to occasionally unlink and delete individual prims that present us with the choice of having a fat strand of hair clipping through the hat or resizing the hat to stupid proportions that make both the hat and the hair look like a noobs cut&paste job. Remember that a hat conforms to the head and compresses hair, and if it has to look like the hat is floating on top of hair then it's going to look like crap.. the only way to do it right is to size and position the hat to the av, then zap the hair prims that clip through it. No-mod resize scripts are fine, which will render the entire item no-mod while those scripts are present. I get that and resize scripts make it a lot easier for some users to fit anything to their av. Once the hair is fitted and the scripts are deleted, though, folks are potentially going to want to add a hat and that absolutely REQUIRES that the hair has mod perms - the alternative is that the hat (a product of another creators hard work) or your hair creation or both end up looking cartoonish and like crap. Setting prims or meshes in avatar attachments like hair no-mod gives you NO protection against IP theft and just pisses off your customers (yes, I got burned by failing to check and buying no-mod hair that looked great uncovered but that I cannot fit any of the dozens of hats in my wardrobe to without it looking like *bleep*)

Cathy Foil wrote: Hadet Sonnenkern wrote: In all seriousness Pivots stilla ren't fixed? We're having to use this ridiculous bounding box workaround when pivots export perfectly fine in Collada format for other programs? Am I missing something or is this still the case? My object pivots perfectly in Unity, Max and Torque. Yep the pivot point of a mesh is still determined by the meshes actual center point. So yea we still have to do the workaround were we have to add invisible faces away from our meshes so that the pivot point appears to be offset but is really just the center point of the mesh. Ridiculous I know. Alternatively, dont be so lazy when scripting their rotation. LSL code to rotate an object around an arbitrary point is pretty easy, theres even example on the rotation wiki page.

Medhue Simoni wrote: it would be cool to have a shortcut key that allows you to cycle thru UI's, instead of opening more windows. Ctrl-Up is your friend there... it toggles the subwindow that currently encloses the pointer fullscreen... So there I am in the 3d view fullscreen tweaking seams [ctrl-up] toggle back to my personal default view where I can see properties and an image editor as well, U to unwrap, slide the mouse into the (small) image editor, [Ctrl-Up] to set that fullscreen and tweeak the UV layout, [Ctrl-Up] back to my default view... you get the point Its at the stage where my right middle finger and thumb pretty much do the combo as a single keystroke. Particularly when frequently switching between watching the anim play out in the 3d view and making fine edits in other windows you might find a little of the same might fit your workflow too

Stephan Gaudio wrote: ...Is it possible to set the priority just for specific body parts? Yes it is, but you will need to use a tool to make it that can export to the internal .anim format instead of .bvh and upload it using a viewer that can do so. This is a capability that many TPVs have had for a while, simply skipping the bvh to anim conversion when an anim format file was being processed through the bulk upload process. In the anim format priority is a per-bone property.

I find my workflow incorporates Drongles advice too. I've found good LI results by doing my best to mark seams ONLY on edges that I have already marked as sharp - Often you cant keep ALL the seams running down sharp edges but the more you can achieve it the better the results will be. Then, with all the seams marked and the model unwrapped, I get every texture layer I want baked. Then as the last stage before export, I clear all the sharp markings on edges and make sure every face is shaded smooth. Since I baked the textures while they were still marked sharp the look of the uploaded and textured model will reflect that and produce the illusion that they are still sharp edges on a smoothly shaded model, but only those edges that are part of seams get duplicated vertex data.

Excuse the hijack, but Drongle - your willingness to help folks out on here and your persistent picking at apparent anomalies in the mesh infrastructure are inspiring. Just wanting to thank you for explaining the math behind some of my mesh "WTF????" moments and recognize a truly outstanding contributor to the mesh modelling community. I've been involved with a few FOSS software projects and with your helpfulness on this forum you;re surpassing many of the most respected contributors on most of those. Kudos richly deserved.