Jump to content

Koruzarius

Member
  • Posts

    72
  • Joined

  • Last visited

Posts posted by Koruzarius

  1. Can we get the getPlayerPosition and direction vectors available *on a screen*? I've been trying to implement some AR features for many months now, and the quaternions stymied me, but now with the screens all rendering for each player individually it feels like all the pieces are in place to do some basic AR work, but the screen doesn't actually have the player location, and basing it off of a programming board means that it will only apply properly for one person, when there's no reason each person couldn't have their own proper view.

     

    I'm going to try to implement it anyway, but it will be clunky by comparison...

  2. While I would enjoy some AvA combat, I don't see that coming for some time, and it will probably require a lot of mechanical rework, so I'm not thinking too heavily on that right now.

     

    I'm wondering how maneuver tool mechanics will work... One of the major weaknesses of docking as I've seen it is that if you are in someone else's tile, they can rip your docked constructs off of your ship, and that can cause some brutal headaches. With this new system, can the maneuver tool affect the whole group of constructs, not individual ones? Force separation of docked constructs to happen through one of those UI options, maybe?

  3. 2 hours ago, CptLoRes said:

    Nice project. Reminds me of old skool demo scene stuff.

    But I also have to be a bit of a downer, since I have a feeling CSS 3D transformations would not only be simpler, but also much faster.

    Simpler, quite probably! This was quite a lot of work =D

     

    But faster? I honestly really doubt it. This is some very very basic level stuff, there's very few operations involved in each of these steps, and the amount of data being transferred over the server is also minimal, just the 50 kb (45kb of which is the teapot itself) one time, then the client's computer handles all of the processing. That said, it's also pretty limited in its ability, I kept the code pretty tight and efficient, but the trade-off is it isn't super versatile. It can handle any OBJ file that has faces that only have 3 vertices each. I'll expand it out later (probably) but the more versatile you get the slower and more bulky it becomes.

     

    The loading step at the beginning could probably go 10-100x faster, I seriously lowballed how much processing to do at each step, I may optimize that later, I just wanted to be absolutely certain it wouldn't overload!

×
×
  • Create New...