ModelDrawer interface

[SpliFF]

As you may know I'm working on a generic model loader. I was looking at the structure of the rendering routines and I noticed that the line between rendering a model and rendering a unit has become somewhat blurred.

Also I notice a lot of modeltype if/else tests which I need to extend to support a third model format.

Since this is C++ I'd prefer to convert these decision trees into class members and build a rendering class for each model type.

Instead of (UnitDrawer.cpp):

Code: Select all

	if (unit->model->type==MODELTYPE_S3O) {
		if (unit->isCloaked) {
			drawCloakedS3O.push_back(unit);
		} else {
			QueS3ODraw(unit, unit->model->textureType);
		}
	} else {
		if (unit->isCloaked) {
			drawCloaked.push_back(unit);
		} else {
			DrawUnitNow(unit);
		}
	}

I'm thinking:

Code: Select all

if (unit->isCloaked) {
  unit->model->DrawCloaked();
} else {
  unit->model->Draw();
}

So that instructions specific to model types are in the model class (which is S3OModel, 3DOModel, etc). Instructions common to all formats would either go in 3DModel.cpp (the model base class) or maybe ModelDrawer (a rendering class) or remain in UnitDrawer.cpp depending on whether they are unit or model specific.

This would also have the benefit of allowing models loaded via Lua or other systems to be rendered without being game objects (such as for UI or SFX purposes).

It's a fairly big job so before I start does anyone have any concerns or suggestions regarding this change?

[Warlord Zsinj]

Nifty; one thing I was always interested in is getting a modelled object that could sit just above the terrain - basically a feature, but a feature that units could walk on. The reason I wanted it to be a feature was so that it could have a specular map, as well as no vertical distortion.

[imbaczek]

suggest model->Draw(float alpha), so it'll be easy (easier?) to draw transparent features (easy way to fading out features from there, if features are using the same model...)

[AF]

I was going to suggest that cloaking is not a property of the model and instead we should give the model attributes which are then set when the unit cloaks to control is visuals, e.g. alpha transparency etc...

Eitherway the two different drawing calls seem like something went wrong somewhere and theres not enough seperation between game mechanics and rendering systems

[jK]

erm

If you OO such functions, how do you will avoid redundant state
changes (rendering a 3do, then a s3o and then again a 3do etc.)?

Also the ModelDrawer isn't abstracted yet as you have noticed already.
But you can't abstract it as an model loader, instead you have to use
SceneGraphs for those, which are already on my todo list.

[Kloot]

So that instructions specific to model types are in the model class (which is S3OModel, 3DOModel, etc). Instructions common to all formats would either go in 3DModel.cpp (the model base class) or maybe ModelDrawer (a rendering class) or remain in UnitDrawer.cpp depending on whether they are unit or model specific.

3DO and S3O already have little in common except for how their geometry is processed, that's why the unit drawer class renders models in batches (so the 3DO / S3O setup and teardown state changes aren't executed needlessly often). With more formats that becomes an even bigger issue, so you will need to maintain a type ordering of some kind anyway.

This would also have the benefit of allowing models loaded via Lua or other systems to be rendered without being game objects (such as for UI or SFX purposes).

FYI, that has been supported by the Lua API for both 3DO and S3O for a long time.

[AF]

store them separatley? No reason why they cant share a common API, would nonetheless be useful elsewhere too

[Pressure Line]

This would also have the benefit of allowing models loaded via Lua or other systems to be rendered without being game objects (such as for UI or SFX purposes).

FYI, that has been supported by the Lua API for both 3DO and S3O for a long time.

Yes. Yes it has. loadmodel.lua has been sitting in the spring/luaui/ folder for as long as i can remember.

[SpliFF]

If you OO such functions, how do you will avoid redundant state changes (rendering a 3do, then a s3o and then again a 3do etc.)?

I guess I would store a pointer to a global ModelDrawer instance in each model instance and add models to an array for that type with something like model->drawer->AddModel(model, alpha) - Then finally call S30ModelDrawer->DrawQueue(), 3DOModelDrawer->DrawQueue(), etc.. to set the state and perform the actual drawing of the display lists or queued model pointers.

Thanks for all the feedback, I won't say much more until I've tested this.