Sign up Calendar Latest Topics
 
 
 


Note: This topic is locked. No new replies will be accepted.


Reply
  Author   Comment   Page 1 of 3      1   2   3   Next
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #1 
With the next release, ArtClientLib will be renamed to Interface for Artemis Networking, or IAN. In this thread I intend to talk about the changes that are coming as I work on them. If you are interested in being notified of updates as I post them here, click the "Subscribe" button near the bottom of the page.

One thing I'm doing is discarding the old Ant build system and restructuring it as a Maven project. With that and the rename, it makes sense also to go ahead and refactor it under my own namespace: com.walkertribe.ian.

Another big change is that I'm adding the ability to render wireframes or silhouettes of the vessels and other game objects onto a graphics context you provide. One consequence of this is that I will no longer bundle the default vesselData.xml and related files with the project. The reason for this is that in order to render the ships, I would need the mesh files, and I do not wish to bundle them with the project as they are art assets that belong to the game. So from this release forward, IAN will require that you set the Artemis install directory before you do anything.

Also, I'm updating IAN to support Artemis 2.3 and making a few other tweaks. Thus far I've made the following changes:
  • Added support for the comms ability to request that a base build plasma shock torpedoes.
  • Convenience method to obtain the proper BaseMessage for building ordnance by passing in the appropriate OrdnanceType.
  • Updated PlayerParser and CreatureParser to handle changes in those object type structures.
  • Added Fighter console enum value.
  • Added FighterBayStatus packet handling.
  • VesselData now correctly stores all art file paths instead of just the last instance encountered of each type. (This only really affects the original base type, if I remember correctly.)
  • Created a parser to read mesh data from .dxs files. Mesh data can be read from any vessel, all creatures except the classic space monster, and some other object types (mines, anomalies, asteroids and drones).
JordanLongstaff

Registered:
Posts: 68
Reply with quote  #2 
I think you've made an awesome amount of progress so far! Reading more into your intended changes, though, I'm a little concerned. I use ArtClientLib for an Android app I've developed, which has me worried about using IAN for it now because of your alleged requirement that I specify the install location (presumably for vesselData.xml and the other assets). The problem is, I know about an install location on my computer, which I use to install the develop the app and then install it on my phone, but unless I need to download the Artemis app for Android to get a location for vesselData.xml, I don't see how I can satisfy this requirement. Do you know if there's still a way I can use this in my Android app? Could I perhaps copy the install files into my project?
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #3 
Hmm, that's a good point, and something I should have considered earlier. I should note, though, that IAN loads data on demand, so a missing file won't cause a problem unless you actually use something which requires it.

There are three kinds of files that IAN looks at in the Artemis install directory:
  • vesselData.xml: This is required for IAN to function properly and you can't avoid loading it.
  • .snt files: Used to read the internal system node grids for vessels (as seen on the engineering console, for example). Required only if you invoke Vessel.getInternals().
  • .dxs files: Used to read the 3D meshes for vessels and other game objects. Required only if you invoke getModel() on various classes in the unreleased version of IAN that I'm currently working on.
So if your application won't need the .snt or .dxs files, you can omit them and just include vesselData.xml.

There are several reasons why I wanted to move away from bundling Artemis resource files in IAN:
  • Requiring access to an Artemis install encourages people to be properly licensed.
  • The bundled files won't work anyway if the server is modded.
  • The files are part of Thom's IP. In the case of vesselData.xml and the .snt files, it's not as big a deal, since players regularly redistribute modded versions of them all the time. The .dxs files, however, are original art assets from the game, so I feel that redistributing those crosses a line.
It should be noted that theoretically, you don't actually have to point IAN to an Artemis install on the local machine. If any machine on the local network has an Artemis install on it, you can simply expose that directory as a network share and point IAN at that.

Here are my options as I see it:
  • Delegate responsibility for locating any game resources to the applications which consume IAN. This was what I was originally planning to do before this concern was raised.
  • Continue to bundle the stock version of vesselData.xml and the .snt files so that IAN will work for almost everything out of the box. If your application requires access to meshes, it would still be responsible for locating them.
  • For Android, perhaps I could figure out a way to locate the Artemis install on the device automatically. This would, however, require that the Artemis client be installed on the device, and of course wouldn't work if the server version is later than the one supported by the client. Also, I'm not 100% sure that Android's security mechanisms will even allow me access to another application's files.
  • Create a simple tool that that makes it easy to extract the required files from an Artemis install and compress them into a single resource file. This file would then be provided to your application. This would make the resources available for machines that don't have an Artemis install available.
ryleyra

Registered:
Posts: 2,846
Reply with quote  #4 
One possibility is to take the install files from a PC installation, place them in an Artemis folder, and point the Android install of IAN to that. The files Artemis Android uses are identical, and nothing says you have to point IAH to the files Artemis is USING. It just needs a copy, right?

That being said, I hope Thom considers opening up the resource directory on Android and making it available in user managed space. I've opened up the .apk, and all the files are there, they're just inaccessible to the user. Giving access to those files will allow Android to be modded, and even open up scripted missions for use by 100% tablet users.
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #5 
Yeah, IAN doesn't care if it's a real install. All that matters to IAN are that the files that it is looking for are in the expected locations. So when you give it an Artemis install directory, IAN is only going to look for the vesselData.xml, *.snt and *.dxs files under the dat subdirectory; all other files from the Artemis install can be omitted and IAN won't care.



I have a question for the math geeks out there. I'm trying to make it so that the 3D mesh can be rendered at any heading and pitch, so that you can have a nice, slowly-rotating wireframe in your client or something like that. So I'm having to dredge up my old trigonometry knowledge from high school, and there's something I'm doing wrong. I'll explain below, and hopefully someone can point out the mistake.

A .dxs file is an XML document. In one part of the document, you find a <vertices> element, which contains a bunch of <vertex> elements that identify points in 3D Cartesian coordinate space (x, y, z). Each vertex has an ID by which it can be referenced. Also in the document you find a <polygons> element, which contains a bunch of <poly> elements. Each <poly> element contains <vertex> elements, each of which has a vid attribute which references a previously-declared vertex under the <vertices> element. This describes the polygon as a series of vertices connected by lines.

Now I want to be able to rotate this model freely, so to more easily do that, I convert the vertices from Cartesian to spherical coordinates as I read them in. Here's the code I wrote to do this:

Vertex(double x, double y, double z) {
  double base = Math.sqrt(x * x + z * z);
  t = Math.atan2(z, x);               // theta
  r = Math.sqrt(base * base + y * y); // r
  p = Math.atan2(y, base);            // phi
}

So imagine a line segment going from the point down to the x-z plane, and connect the endpoints of that line segment to the origin to form a right triangle. Phi is the measure of the angle of that triangle connected at the origin, theta is then the measure of the angle to the base of that triangle on the x-z plane, and r is the length of the hypotenuse, the distance between the origin and the point.

Now I need to rotate and scale the vertices, then convert them back to Cartesian in order to render the model. Given the parameters scale, theta and phi, I perform the following computation:

double rFinal = r * scale;
double tFinal = t + theta;
double pFinal = p + phi;
double base = rFinal * Math.cos(pFinal);
double x = base * Math.cos(tFinal);
double y = rFinal * Math.sin(pFinal);
double z = base * Math.sin(tFinal);

(Note: Originally, I had used formulae I had found in my online searches to compute x, y and z without the need to compute base separately, but when this wasn't working, I tried breaking it down into solving two triangles in 2D space to simplify debugging.)

Once that's done, I then project onto a 2D plane. In my case, I don't particularly care about perspective, so I just omit one axis. When I try this and render the wireframe with rotation values of theta = 0 and phi = 0, the model comes out great. And when I manipulate theta, the ship's heading changes just as I would expect. But when I manipulate phi, which I would expect to change the vessel's pitch, the ship instead seems to turn inside out! This would a pretty cool effect for the ship getting sucked into a black hole or something, but it's not exactly what I'm looking for!

model.gif 

Any thoughts as to what I'm doing wrong?


ryleyra

Registered:
Posts: 2,846
Reply with quote  #6 
According to the Internet, x, y and z should be as follows:

double x = rFinal * Math.sin(pFinal) * Math.cos(tFinal);
double y = rFinal * Math.sin(pFinal) * Math.sin(tFinal);
double z = rFinal * Math.cos(pFinal);

But Artemis swaps the y and z axes, so we get:

double x = rFinal * Math.sin(pFinal) * Math.cos(tFinal);
double y = rFinal * Math.cos(pFinal);

double z = rFinal * Math.sin(pFinal) * Math.sin(tFinal);

So I think you have switched sin for cos in your base and y coordinate:

double base = rFinal * Math.sin(pFinal);  // <== switch here
double x = base * Math.cos(tFinal);       // <== is fine
double y = rFinal * Math.cos(pFinal);     // <== switch here
double z = base * Math.sin(tFinal);       // <== is fine

Base is essentially the r value in the triangle in the x-z plane, and y is the height of the point. Remember that cosine is the length of the side next to the theta angle (y); sine is the length of the side opposite the angle. (the line perpendicular to r that passes through the point)

You may also need to switch x, y or z to make it negative. This would flip the model over or mirror it left to right. (I'll note the game itself isn't consistent about left to right mirroring)
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #7 
Sadly, all that has done is change the phase; it now starts collapsed and still turns inside out as phi changes. Makes sense, since sine and cosine are basically equivalent with a pi/2 phase shift. I'll keep fiddling around with it, but it's really driving me up the wall.
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #8 
I believe I have realized what's happening: I'm applying the phi rotation to each point individually instead of to the model as a whole. Each point is being folded up towards the y-axis! Instead, I need the variable currently represented by phi to be the angle relative to a line parallel to the y-axis intersecting the x-axis at the point's x-coordinate, not the y-axis itself. I'll have to sit down and figure out the math for that, but I think that will work.
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #9 
Success! Turns out what I needed to do was use transformation matrices to scale and rotate the mesh. There are some libraries out there that can do this, but they all seemed like overkill compared to what I needed, so I quickly coded together a class that can do matrix multiplication, built the rotation and scaling matrices, and plugged them in. And it worked! I can now draw the wireframe models while applying rotations on all three axes. Here's a render of an Arvonian fighter as an example:

arvonianfighter.png

ryleyra

Registered:
Posts: 2,846
Reply with quote  #10 
Excellent. Those wireframes look really nice.

Hey, you know what I would like to see? A firing arcs diagram. That wouldn't just be useful as an informational display, but it would be helpful for debugging and mod creation.

Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #11 
Has anyone captured the packet sent to the server when comms demands that an enemy base cease operations? I'll get to it eventually, but if someone else gets it first... [biggrin]
Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #12 
Doing more work on model rendering. I refactored the code so that all the variables that affect the render (rotation, translation, scaling, color) are now contained in a RenderParams class so that they can be more easily passed around.

In addition to wireframe and solid (silhouette), I've added a hybrid "solid wireframe" render mode: it looks like a wireframe, but the model isn't transparent and you can only see the wires on the side facing the camera. This makes a lot of the complex models look much cleaner. As an example, below are two renders of the carrier. The first uses the traditional wireframe render, while the second uses the "solid wireframe" render:

carrier-wireframe.png 
carrier-solid-wireframe.png 

One thing I don't like is that currently the class which contains the data about the 3D models also is responsible for performing the rendering. I'm not a fan of this because I would like for the project which consumes IAN to have more control over the render if it wants. At the same time, I do want rendering to work out of the box. So I think I'm going to create a ModelRenderer interface, and break the rendering code off into a class which implements ModelRenderer. That way, if you want to tweak how models are rendered you can simply override the appropriate methods on the default renderer, but if you want to make more radical changes, you can create a completely new class that implements ModelRenderer.

I don't have any intention of building a complete 3D renderer into IAN; that's a task better suited to libraries that specialize in that sort of thing. I don't intend to support perspective rendering or applying textures and such. But I do want to provide some simple renders such as these so that they can be used out of the box.

The last two tasks I intend to tackle for model rendering are:
  • Adding internal system nodes to the render pipleline
  • Facilitating pre-rendering of top-down silhouettes so that they can be drawn much faster in real time

ryleyra

Registered:
Posts: 2,846
Reply with quote  #13 
That looks even better!

As an experienced user of Java and C#, I can empathize with your desire to separate out the rendering code from a data model. When those features are coded into the same object, it can be a real pain to make tweaks without breaking everything. And yet, pulling out the code for a subfeature can be a feat. Good luck, and it's always a good idea in the long run, so it's well worth the time and effort.

I'm getting very familiar with ArtClientLib with the work I'm doing on the WarServerProxy. I'm not using the built in packet types, merely parsing them manually and only using the information a need, but it's been quite an education. I'm sure what I've learned will pay off dividends with other projects down the road.

And I'm happy that I've been able to make the War Proxy work with 2.3, without having to wait for IAN.

Arkantos

Avatar / Picture

Registered:
Posts: 419
Reply with quote  #14 
Well, maybe I'm just a smart developer, because I've already successfully decoupled the rendering code. Glad to hear you're making progress on your project!
ryleyra

Registered:
Posts: 2,846
Reply with quote  #15 
It helps to design it right to start with. [biggrin]
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.