Jump to content

chriscalef

Members
  • Posts

    399
  • Joined

  • Last visited

Posts posted by chriscalef

  1. Huh, okay. Thanks for the info!


    Arduino shield sounds useful, I'm into doing less work whenever possible. :-)


    Can't allow this project to creep onto the front burner right now, but I'll definitely pick up at least a sample kit and see if I can get anywhere. Thanks again for your help!

  2. Wow, okay, so take it slow with me here for a second...


    In terms of the chips themselves, if I'm satisfied with a slow boat from China it looks like here's an example of where I could find the MPU:


    https://www.aliexpress.com/item/GY-521-MPU-6050-MPU6050-Module-3-Axis-analog-gyro-sensors-3-Axis-Accelerometer-Module/32340949017.html


    And here's a potential 8266 source:


    http://www.gearbest.com/transmitters-receivers-module/pp_227650.html?currency=USD&gclid=CJ7mjpzuks8CFYllfgodEqAKlQ


    There are many options but it looks pretty easy to end up with both of those for under five bucks.


    However, what else do I need then? Apparently some perf board that I'd cut up into little squares... (total novice here, sorry). And then I'm not sure what the white board is that they've attached the 8266 to, but I'm not seeing any chips I can buy that come with that, yet.


    And then, a couple of resistors and those two buttons - don't know what they're used for but they're probably important.


    And, any guesses as to how this little bad boy would be powered? I don't see any wires leading to a battery pack, so maybe he's got a little button battery sandwiched between the two squares of perf board? Any idea how I'd figure out how much power I'd need for this little rig? I might also be tempted to run wires from a wearable battery pack, just because button batteries are so evil (we don't have little kids but I've heard terrible stories online about what happens when they get eaten). :-0


    Oh, and then last question, do you suppose my typical home comcast router would be able to juggle twenty or so wifi signals all streaming UDP data to my PC, or would I need a fancier wifi router?


    Oh yeah, and then _really_ the last question, ;) how do you go about programming these things? I guess he's got the drivers included in his github project, but how do I go about transferring them from my PC to each unit? USB cable with an end to match those pins, I guess?


    Thanks again for bringing this up and bearing with my ignorance! I do have a friend nearby who can help me with the physical manufacturing aspects if I can figure out the technical details.


    This is exciting stuff! I've seen accelerometer based mocap suits going for well into the five digits, I'm very much liking the sound of a low three digit competitor to that!

  3. Right on.


    Well, I downloaded, built and ran the c# project from github, no problems there. And I found many sources for the MPU6050 units, some of them getting down to less than $2 each!


    I'm a little confused about the rest of the pictured hardware, however, and am not experienced at the circuit construction / arduino end of things at all. Clearly you need a wifi chip for each one, and then some other stuff. I didn't look exhaustively but so far haven't found the guide for building his sensors. Any idea what the rest of the parts are and how they might go together?

  4. @flysouth I am very interested! Have you experimented with these units? I've been thinking somebody should be doing exactly this for years but I never went there myself, so glad to hear somebody else did! Love it when that happens! :-)


    Thanks for the link!

  5. As far as I can tell, your calculations seem correct. Only input I have in terms of it feeling weird are:


    A) torque vehicles have always felt pretty weird to me under the best of circumstances (really looking forward to having full physX vehicles, I saw a note about that from a commit three months ago on the dev branch...?)


    and then of course,


    B) driving even a real vehicle at 55 mph on anything but a flat road surface likely feels pretty out of control as well.


    But mainly I think better physics might be what you're looking for. Torque vehicles have always felt very "floaty" and non realistic to me. I've never tried to make a vehicle game so I didn't spend a whole lot of time trying to tweak them, but that's always been my impression.

  6. Could anyone possibly point me in the direction of where exactly the mission editor / world editor pauses the (at least physx) physics simulation? I'll probably find it immediately now that I've publicly admitted my problem. But this behavior is highly undesirable for my particular application.


    @Timmy perhaps?

  7. If you haven't accounted for the curvature of your planet, aren't you guaranteed to fail? Your player hasn't moved along a straight vector, he has rotated around a tiny arc of a circle with its center in the center of the planet.


    It might help you to imagine the problem as if your player was moving around a significant chunk of the planet in one go, instead of just a few kilometers. It would seem that instead of simply adding a vector to all of your points, you need to actually rotate them around the center of the planet, by some small amount.


    For instance, if you were to move your player around a full ninety degrees of the planet, the way you are doing it now the ground that had been under his feet would be moved down and over and would be exactly perpendicular to what the ground should be doing at that point.

  8. Just what does your Oracle system do? Is it for persistence or frame by frame updates? Can you really hit it for player positions 32+ times a second, for all players? My only experience of anything database related is that interacting with them is far slower than that, but maybe what you have is a game-specific application designed for just what you are trying to do.


    For what I'm used to doing with online games and databases, you would use the Torque networking for all the frame by frame updates, and then check in with the database periodically to save current position and sanity check the current state, etc., but I've never (in my admittedly old school, limited experience) heard of anyone using a database for realtime, frame by frame game state updates.

  9. AHHHH, OMFG.


    Very sorry for any wasted time anyone spent thinking about my little problem here, because I just realized it was, once again, entirely my own fault. :-P


    Turns out it was an artifact of some changes I myself made to my build's collada import process, way back in 2011, for the purpose of fixing a problem related to playing animations on imported collada figures. The problem stemmed from the way stock Torque "fixes" handedness on incoming collada models.


    I say "fixes", because the stock method is simply to rotate the figure from Y up to Z up, without changing the actual left/right handedness of the nodes. Sorry I can't explain it better right now but the end result was that if I had a bunch of animations made for a right handed Torque character, and then I brought in a left handed Collada model with the exact same bone structure, I would expect to be able to play my anims on this collada model, but they did not work as expected.


    My hackish attempt to fix it involved flipping handedness on all the nodes individually, instead of just rotating the model, and it worked at the time for my limited application, but clearly it is puking its guts out on these makehuman/blender models.


    No idea why it took me so long to think of trying a stock Torque build (doh!), but the idea *finally* occurred to me, and sure enough:


    http://opensimearth.com/images/screenshots/blender_dae_t3d_12.jpg


    Perfect.


    So, anyway, some work to do on my end sorting out whether it's possible to fix my original problem without causing this other problem, but at least the issue is resolved, and nobody but me needs to worry about it. :-) Thanks for all the hand holding anyway!

  10. After years of taking on projects that seemed reasonable at first but turned into monstrous quagmires before they were finished, if ever, I can say for sure that if I were you, I would try to work with Torque's existing networking layer before I'd try to strip it all out and replace it. It is very fast, by the way - I wonder if your Oracle system is as efficient in terms the needs of a realtime game, ie using the absolute least number of bits possible for the required data? This is one area where Torque benefits from its history as a first person game engine from the nineties, where everybody needed a smooth framerate while playing Tribes over their dialup modem connections.


    Even if you do rely exclusively on the Oracle system, if your only concern is to make it impossible for players to play multiplayer on their own for free, it seems like you could come up with a myriad of ways to break that functionality without rewriting the whole engine to strip out the network code. I assume you're not going to release your source code, given the concern about exploits, so it would seem that a simple monkey wrench in the right place would be enough to make it impossible to connect to another player without going through your authenticated system.

  11. Huh, well I gotta go AFK for the day, but if anyone who has this working could possibly take the time to recheck their process, I'd sure appreciate it!


    There must be some additional step I'm not doing, because I'm certainly not doing any extra steps to mess it up. As mentioned above, I literally just


    1) open makehuman,

    2) click on a skeleton for the default figure, and

    3) export,


    and then in blender, I just


    1) export to collada.


    I'm guessing I'm probably only missing one all-important click somewhere, but rotating 180 definitely isn't it. (I'm sure it's also necessary, but not causing my main slenderman problem.)


    Re: version, yeah, I'll try to backtrack versions next.


    Thanks for everybody's patience though! Definitely looking forward to having this pipeline hooked up!

  12. Ah, here's some slight progress anyway... in blender, I went to the "Set Origin: Geometry to Origin" option, and found that when I did that, both the mesh and the skeleton centered themselves on the origin, but the skeleton was offset by some distance (a foot or so, in human terms):


    http://opensimearth.com/images/screenshots/blender_dae_t3d_10.jpg


    However, the result of exporting and importing this into Torque was, while not perfect, visibly quite a bit better:


    http://opensimearth.com/images/screenshots/blender_dae_t3d_11.jpg


    As you can see, the slenderman monster on the right actually has some amount of bodily integrity, when compared to the nightmare creature on the left. Hmmm.

  13. @Duion, so there's literally nothing else you did in makehuman or in blender, relevant to this problem, besides the -180 degree rotation? Because I am literally just opening up makehuman now, taking the default character, giving it a default skeleton, exporting a collada file, opening that collada file in blender, either rotating or not rotating it 180 degrees, and exporting as collada. Result every time is a slenderman horror beast.


    I'm on makehuman 1.1.0, blender 2.71, just for reference.


    Oh, and, results are the same exporting to blender using mxh2 format, as well.

  14. Well, I've clearly got something different going on here. Rotating my character resulted in the same mess, only rotated 180 degrees:


    http://opensimearth.com/images/screenshots/blender_dae_t3d_08.jpg


    Messing with the bone orientations in makehuman (along local x, along local y) definitely changes things, but not in a way you could describe as better:


    http://opensimearth.com/images/screenshots/blender_dae_t3d_09.jpg


    Thanks for confirming this does work for somebody, though! Definitely good to know it can work without serious engine changes. It's probably just some global/local checkbox somewhere...

×
×
  • Create New...