Experiments in loading client side geometry

With the ability to draw arbitrary geometry in 3D space on the client side available, I decided to try to determine realistic upper limits on its capabilities. I figured I could try constructing squares (two triangles) with variable colors, in the form of an image.

I wrote an image file parser that generated relevant T2 script calls, and attempted to run it on my client. The script used to insert the images visible in the attachments is 3 MB, with a 2.54 MB DSO, and around 40,000 function calls per drawn frame. The script system isn't really capable of pushing these sorts of rates, and as a result, the framerate was far from playable (think about 1 FPS).

The first image shows a bug in my image parser (Blue/Red swapped, and vertical flipped), which I fixed before taking the other images.

Edit: Added an opacity reduced version so the triangle grid structure is visible.
«1

Comments

  • Heh... That grid looks cool
  • Lol, wow. Who is that anyway?
  • That makes me think of some Valve games.
  • That's pretty interesting.
    I doubt drawing an image would ever really be practical in construction, but using a single scaled solid colour polyhedron over a space would be pretty useful in filling in those hard to get spaces. I imagine if used it can only be seen by the client running it, right? Or if made to be seen by other players on a server by some means it would not require all players to have the clientside modifications... You could imagine how few people might join a server if required elements are made to be clientside. :p
  • That's pretty interesting.
    I doubt drawing an image would ever really be practical in construction, but using a single scaled solid colour polyhedron over a space would be pretty useful in filling in those hard to get spaces. I imagine if used it can only be seen by the client running it, right? Or if made to be seen by other players on a server by some means it would not require all players to have the clientside modifications... You could imagine how few people might join a server if required elements are made to be clientside.

    I think this little experiment effectively demonstrated that image drawing isn't practical. It was just a cute thing to try. I've also done a Conway's Game of Life simulation that was 128x128 boxes, which worked very well.

    This could easily be the basis of a polyhedron "pack" of some sort. On the server end, there would be a polyhedral physical zone (invisible, but solid), and the server would send that polyhedron information to the client, so a client side script could build the necessary triangles.

    The downside would be that clients without that script might be running into a lot of invisible physical zones that they couldn't see. This system also isn't really ready for prime-time yet. Zooming is non-functional while overlaying geometry, as are deployed beacons (green/yellow circles). A bit more work is necessary on the client side to prevent polygon flood, allow zooming, apply reasonable flat shading, and a few other things. I don't think it would substantially impact game play in a negative manner for those without the client, compared to the positive impact it would have on the clients who do. Include it as part of a "Construction Essential Pack", with a few of the common maps, and the impact should be minimal.

    I think it is also worth mentioning, that since these polygons don't count as ghosts, they aren't subject to the same 1024 object limitation as are the regular static shapes. Small curved parts of buildings might also be possible without substantially affecting frame rate.
    Lol, wow. Who is that anyway?
    A friend of mine, who I hold in very high regard.
    That makes me think of some Valve games.
    How so?
  • How could you upload something like that?
    Did it lag?
  • How so?
    You could spray-paint certain pictures on to the map.
  • Wouldnt it be better to attach to an lsb pad?
  • Attach what to an LSB pad?
  • The uploaded Picture
  • For what purpose?
  • I think he means put the picture on an LSB like a picture frame or something. Gives it more taste or whatever you wanna call it.

    If you ask me, you could just (if we end up making a pack for it) deploy it on an LSB or move it client-side to an LSB.
  • Yea, attach the pic to an lsb, and therfore, a fun deployable to customise around with =)
  • Mm, looks complicated to make it render something client side - without the server sending the information to you.
  • I am working on a .obj format model loader now with a global illumination flat shading applied. With rotation and rescaling support, it would be pretty easy to write a server->client geometry drawing interface. I'll post screen shots of the Utah teapot once I succeed.
  • Utah Teapot?
  • Utah teapot test screen shots attached. I'm not exactly sure what is going on, but it looks like a bit more than half of the teapot has scrambled geometry.

    It looks like my flat shading is close to correct, but it is hard to tell with the screwed up geometry.

    Edit: Oops. Looks like vertex numbering in .obj models starts with 1, not 0. I fixed that in my loader and got a model that looks almost perfect. There is still what looks like an extra face, but as you can see, the result looks much better than the first two screen shots.
    • screen1.png
    • screen2.png
    • screen3.png
    • screen4.png
    • screen5.png
    • screen6.png
  • Nice....
    whos ship in background?
  • Now it looks even more complicated to load actual 3D models...


    Edit:
    It's possible to load .obj files in Tribes 2? Or does Tribes 2 need to be "Hacked" in any way?
  • Hackery...?
  • .obj model files are just ASCII. Each line describes either a vertex (as a set of 3 floating point numbers, as coordinates in 3D space), a face (3 vertex references), or slightly more exotic things, like texture coordinates, or vertex normals. You can easily write a script to read those sorts of files and put the relevant information into an object (in this case, I call them Virtual Meshes).

    The virtual meshes have a position, the vertex coordinates, which vertex groups form faces, and some light shading calculations (so the thing isn't one big blob of one color) that involve calculating normals and some basic vector operations to calculate available light without self occlusion.

    Once all of that data is available, it is just a matter of issuing commands to draw triangles. This requires a small change to the PlayGUI object, but that is something accomplished purely with script modifications.

    No machine code level modifications, if that is what you are asking.
  • So basically, we can get pictures to come to life?
  • niceee.

    Soon we'll be importing jpeg's!
  • t2 can already handle jpgs...
  • What kind of change to the PlayGUI object?
  • t2 can already handle jpgs...

    k, not like I would know.
  • i ask again, whos ship is that?
  • the ship doesn't exist. You saw nothing.
  • the ship doesn't exist. You saw nothing.


    *adds quote to sig*
Sign In or Register to comment.