Shortbutlucky {l Wrote}:Well basically, the goal is to not even need to render a track at all.
My wording was indeed imprecise. I thought STK would still render the items on track, and in flight (but obviously not the actual track).
AR depends on adequate surface mapping technology from the cam in order to augment objects into the real world, so STK would technically only need to handle item appearance, function, and interactivity between the karts. (Aka, kart 1 has fired a plunger, kart 2 has been hit)(kart 3 has received a bowling ball).
But also item positions, which then somehow would need to be forwarded to the helmet/AR. And kart position must always come from the karts, and that would include orientation of the karts (or you would just use a simplified approach in which the karts are always 'pointing in the right direction', ie along the track) - but this issue need to be solved. You will never be able to approximate the kart's position within STK (ok, maybe good enough for a short you tube video of driving with a curve or two

).
Positioning and collision would most likely be best handled by Total Immersion on the AR side of things since they specialize in manipulating position of a 3D object on a real surface.
What kind of collision are you talking of? With items, esp. with moving items like balls? This would then reduce STK to simple move bowling balls around - and I'd say there are easier options to do this, just chuck in a simple physics engine (or even do your own. That would be a lot easier than trying to adopt STK. Just simulate a simple homing missile going directly towards the opponent, or one just going straight

To summarize, whoever the STK expert in this project is would only be responsible for connecting item design, events, and consequences. Total Immersion would handle positioning and collision on the software side. I'm working on positioning systems on the hardware side. Then we'd most likely need someone for networking to link the individual kart events together. A mechE friend of mine is willing to handle the stopping, slowing, and speeding up of the karts.
I still think you are missing the point on how to get the kart position into whatever software system you will be using. Can I recommend sitting down and writing down the actual requirements, and designing what system is doing what precisely? I.e. where are the kart positions coming from (which are necessary in order to determine the position of whatever item is being fired), ...
But otherwise, similar to auria, I won't have time either to work on this. I am more than happy to give you a few hints. E.g. STK can already run without a display, so you would only have to get the item positions out (which is simple enough) and get them to AR/helmet (which you would have to figure out anyway), and figure out how to get the positions from the karts back into STK. And you would need someone to model the track.
Good luck!
Joerg