[razorjack]

Hello,

For someone who doesn't know, I want to implement a planetary engine into FS2SCP like I said in the topic http://www.hard-light.net/forums/index.php/topic,49754.0.html

I need help from programmers who is familiar with the model routines of FS2. The goal is to implement model scaling.
Otherwise I would like to get a hint how to implement scalability into models quickly, without altering the source all too much.

[Nuke]

i figure youd just have to do everything with vector multiply on each model before you do world space transforms on them. most games can do everything with a 4*4 matrix in one pass, but as far as i know freespace only uses 3*3 matrices for everything. youd want to do scale, then rotate and finally transform in that order. of course i really dont know heads or tails about the inner workings of the freespace engine.

[WMCoolmon]

For something like a planet, couldn't you just tweak the model rendering subroutines and physics functions so that the model's size was multiplied by X amount?

[razorjack]

You're both right, but it's nothing new.
I planned to tweak these model subroutines as you said WMCoolmon, but there is about a half MB of source around it (Collision functions, rendering a.s.o.)
It would be great to get any guidance how to scale up by a factor and keep everything possibly bugfree afterwards. That's the reason why I want to get help with programming, too.

For rendering planets: I render a small ball in front of the camera and then clear the Z Buffer afterwards. In other words, the scene is split up into different layers for different "scale classes". I need model scaling because a model should be representable in these different scale classes by keeping the same size.

If a ship is going into lightspeed for example, it simply climbs to another scale class. Automatically it must be scaled down or it will look like an object of planet size.

[WMCoolmon]

Well if you're going to have the planet behind everything, that's no problem. Simply do a search for obj_render_all(), then look before it for anything else that's rendered (eg the existing planets). Render the planet using model_render, then use the zbuffer clear function (gr_zbuffer_clear() or something, I forget). Cockpits are done like that, except they're done after everything else has been rendered.

If you want to scale it, all you need to do is move it closer to the camera when it's rendered, ie pass a different position to model_render than its actual position.
- Do object position - camera position = relative object position (using vm_vec_sub)
- relative object position * scalar constant = new relative object position (using vm_vec_scale; note that the scalar constant would have to be between 0 and 1.)
- camera position + new relative object position = final object position (using vm_vec_add)

Once you had the 'final' object position you would pass that along to model_render. In this way, you would make it possible to enlarge objects by making the renderer treat them as if they're closer than they really are. Since it doesn't matter where they actually are - because you're clearing the zbuffer - the planets will appear huge and massive. You could even screw around with the FOV some to make them look better, as long as you set it back afterwards. But IIRC, changing the FOV is a costly operation in terms of video card resources.

So really, there's no reason to go messing around with the massive chunks of code in modelrender.cpp. Just do everything with the model_render function. You might want to look at object_render() and obj_render_all() to get a feel for how the function is used.


But that assumes that you're talking about planets, which apparently you're not. All of a sudden, 'lightspeed' has entered the mix. So you want to implement 3D planets, atmospheric landings, and a new warp effect all at the same time, and have someone else do the majority of the work? That's not going to work at all. Those things all need to be handled one at a time in order to be done properly.

[razorjack]

But that assumes that you're talking about planets, which apparently you're not. All of a sudden, 'lightspeed' has entered the mix. So you want to implement 3D planets, atmospheric landings, and a new warp effect all at the same time, and have someone else do the majority of the work? That's not going to work at all. Those things all need to be handled one at a time in order to be done properly.

Things like planets and lightspeed will be implemented in order. But first of all I need a stable ground for them.
I'm not concentrating exactly on these aspects. I've created a small concept with rules and I try to make Freespace 2 work with this concept. It's more a mathematical approach to the problem:

The concept says that every math operation should be performed inside a choosen coordinate systems. I must only make sure that vectors or scalars are converted first before they can be used in another coordinate system. And these coordinate systems can have also a scale value. And model routines should stay consistent in this concept, too.

An operational coordinate system inside a routine can be choosen almost freely, but at least there must be one. For example the AI can work inside the system of the NPC ship. By declaring this I must make sure that every vector and scalar which is passed to any AI routine is converted first. The choice of a system influences only the accuracy of float numbers and may lead to performance drop if the conversion is too complicated.

That's the main thing to be done. All other things can be extras.
Anyway thanks for the hints.

[EDIT] It's not right to say that the majority of work is at the model routines