Sirisian

If you had a model renderered and a very basic g buffer you could analyze ssao. The many naive approaches are expensive with tons of optimization routes to research.

Just know that 60 updates per second is a lot. Not sure if this is for the Internet, but with TCP you might see stuttering so you might want to lower that down to 10 to 20 in the future depending on your requirements.

This is a rather complex problem using triangle based rendering. Do you need volumetric type effects where the transparency is dependent on the ray distance? Are the volumes a uniform color usually?

One solution is to triangulate your meshes with the same color into single mesh objects and render both the back and front faces using a DX11 order independent transparency linked list approach storing the beginning and end of each volume then in a second pass change the rendering algorithm to use an opacity rendering equation like this.

The alternative is to raycast on the GPU using 3DDDA which requires DX10/11 hardware. You can use a similar opacity function as the one I linked as you raycast the volume.

Note there is a reason why you don't see this much in games. It requires rather advanced solutions to look correct.

After rating all the games earlier I definitely supported the 100 dollar price to entry. I like that steam only allows quality applications in. The original list, which has had most of the incredibly bad games removed already, was filling up with cheap ipad games with ports to the PC or promises of a port. Many were just flash games I've played for free on newgrounds.

Java or Javascript? Yeah that's all that's really necessary. But yeah you can easily make a game with just HTML5's canvas and Javascript. Or if you meant Java then yes, that has an applet you can use with many ways to make a game. Anything more would depends on the game and your requirements. You left your question kind of open ended.

Ah, I recognise it now :-) Because of the cars I though it was a museum or something. They must have been added seperatly.

Wait a second. I spoke too soon since I just took a quick glance. That doesn't look like that model at all. I've never seen that model he linked with the cars. Now I'm curious also.

Nice pictures! Kind of off topic but where is this scene from: http://twitpic.com/8iohd5/full Is it a freely available test scene or something you aquired privately?

That's actually one of the model's in Laine's SVO papers also. It's Marko Dabrovic's Sibenik Cathedral model. You can find it in a lot of places online. One of them is here.

This also depends on the quality you want to render with and the screen resolution.

For low quality look into raycasting methods. They often rely on single sampling and are extrmely fast with the right algorithms, but their quality with a single sample per pixel is often low. If you want to go that route look into 3DDDA and octree traversal algorithms. They are rather easy to thread. Look at Laine's papers on SVO traversal. Note with some tweaks this method looks very nice.

For medium quality look into cone tracing.

For higher quality (or "perfect" rendering) look into beam tracing.

For naive rendering look into polygon rasterization. In any case read the Larrabee article as it comes up sometimes for things like octree frustum culling. (Similar algorithm).

For handling the framebuffer look into pixeltoaster. Also this goes without saying, but work on your algorithms from a high level and optimize down. When you think you have things right start switching over to SIMD instructions.

Also if you render volumes front to back don't use source alpha minus one blending. It doesn't model volumes. This algorithm does.

The only thing I could find was an article here http://sirisian.com/.../binary-packet/ but it is regarding packing bit by bit, which I am not going to do since I think it would be too CPU intensive for a mobile game.

CPU intensive for who? The client is basically just sending input that might only a be a few bytes. It depends on how twitchy your game is, but since you mentioned mobile I'll assume it's not a 400 apm RTS game. Then for getting the state I'm imagining a fixed update rate that's fairly low like 200 ms at the most? (5 updates per second). Assuming you're not updating hundreds of units at once and are doing sane delta updates I don't think you'd hit anything that would be that CPU intensive to deserialize coming from the server.

That said I wrote these two writers. C++ version. C# version. They are simple binary writers/readers which I wrote for someone that was developing between languages. Basically what's going to help you more than anything is sane delta compression. Not sending anything the client already knows about. Your server should be 100% aware of what the clients know and intelligent in building the per client packets. (I'd give you more information, but I removed my old articles online relating to this so I could rewrite them. Been meaning to get back to that).

// edit also I see my robots.txt isn't stopping people from finding my blog. Interesting.

Also echoing the "support the native resolution" look at the steam hardware survey. Take note how random the resolutions are. Basically everyone just buys random monitors without thinking about it most of the time so supporting everything is key. At the very least support 1920x1080 which is quickly taking over as the dominant resolution.

Have you taken a look at the larrabee rasterization algorithm? If you implement it using a quadtree it optimizes down to a few lines of code and is only a few additions and multiplications using only integers and supports aliasing. It can be specialized for any N-gons. So a quad looks like this and a 50-gon looks like this. Tons of optimizations available and it easy to run parallel. I believe it's the fastest rasterization algorithm, but I haven't seen many compared.

Just delete the post since the community seems to think it's useless.

It's kind of important that you realize why they might think that. From a purely mathematical sense you should be starting in 2D and not 3D. Ideally any normalization algorithm created in 2D will expand to 3D or so I believe.

Also here's a paste of your code running on 100 random vectors. Your algorithm doesn't work at all.

I can't comment on POM, but QDM is a modern way to handle things. There are comparisons to pom in the paper I linked. Must better algorithm overall.

1 - first i need to get the angle in rad of the wheel then transform this angle into a normalized vector right ?
2 - i multiply the normalized vector to the length of the original force right ? (so i get my wheel splitted longitudinal and lateral vector).

Working with radians is kind of pointless. All you need is the vector the wheel the is pointing towards. Then you need a force vector and you can do a vector projection to find out how much of the force is acting in that direction.

Projection, as you probably know, is just 'a' projected onto 'b' which is: c = a . b / (b . b) * b where b doesn't need to be normalized.

So with (0, 5) force and the tire is in the direction (1, 1) then you just do:
(0, 5) . (1, 1) / ((1, 1) . (1, 1)) * (1, 1) = (2.5, 2.5)
and (y, -x) is (1, -1) so:
(0, 5) . (1, -1) / ((1, -1) . (1, -1)) * (1, -1) = (-2.5, 2.5)
Converting an angle for the tire into a direction vector is just: (cos(angle), sin(angle)). I noticed you're converting from degrees to radians. Don't do that. Learn to work and think in radians.

It's helpful to draw a free body diagram when dealing with forces and to remember that a wheel rolls in one direction and only experiences friction perpendicular to this direction in the ideal case where it is freely rolling.

The friction we are dealing with in the second case is static friction with a force of μ * F_n where μ is the coefficient of static friction and F_n is the normal force or in a case of a car F = ma where m is the mass of the vehicle and a is the acceleration of gravity aka g. So you end up with the static friction of F_s = μ * m * g. The tire will only move if the force is enough to overcome the force of the static friction. If it is then kinetic friction is used when the object is in motion relative to the contact surface. The amount of force applied would only be F_n = F - F_s. where F_n is the net force acting on the object. So if I apply 100 N of force to an object with 50 N of static friction at that instantaneous point before it starts to move and kinetic friction takes over I'd only be applying 50 N of force.

The last example assuming the wheel is frictionless when it rolls then the friction force is not acting directly back into your pushing force. Remember how I said on a tire the friction force is perpendicular to the rolling direction? So you have a 45 degree angle. If you project your force vector onto both axii you'll find your 5 N of force is "]split. So in the direction of the roll we have (2.5, 2.5) as the force vector. And perpendicular we have (-5/2, 5/2). Depending on the amount of friction force that force might be totally stopped leaving only the force in the rolling direction. If the force is greater than the friction force you end up drifting.