PR Joint Project Bits

You may also want to check out

http://sense3.iwarp.com/slizer.html

for the first of the alien series

Cheers
Darrin

The Skies look good dude ...
Can't we mix C & C++ I think it is possible

Nat

Edited by - nat on 4/10/00 10:02:40 PM

C/C++ Should be ok, if it is done properley, I usually end up mixing up both together most of time anyways

Any of you guys get a e-mail from those age of darkness doods??

The alien meshes are awsome dood!

Cheers Guys,
Az, I have done a bit of work since I sent you the meshes.
Check http://sense3.iwarp.com/slizer.html

I agree with your comments, will animate the mandible.
The Alien Meshes are quite a low poly count as is, could probably reduce it more tho. Also could implement some LOD for meshes. ie in the distance replace all of the segs with really lo poly meshes.

The aliens do need some sort of weaponary/sheilds. I am a bit unsure about armour tho, they are already naturally armoured.

I will use my site for temporary graphics postings, and will notify you when any changes are made.

Cheers
Darrin

Friendly advice: I wouldn''t mix C and C++ code if I were you. That would make for some hellacious code maintenance.

I think mixing C/C++ is ok.

Suppose you were writing aliens AI. Put it in a seperate file alienai.c/alienai.cpp then make two or three funtions which will be called from the main file. One could be the Initialization and the other would be the one in the main loop .

If any Globals have to be called put them as comments in the same file starting. This will make the integration a lot easier. I normally follow this

Any way this is what I think .. what do u guys think ?

You can''t have two files named alienai.* inside the same project. One of them has to be compiled to object code (alienai.obj), and the compiler will not know which one is to be used for that. Try it if you don''t believe me.

Why are you wanting to mix them anyways? There aren''t any advantages. Just use one or the other inside each project.

No problems arise when you are creating seperate libraries to be linked together, but you have to make sure you declare your stuff as ''extern "c"'' from your C++ code.

>>The Alien Meshes are quite a low poly count as is, could probably reduce it more tho. Also could implement some LOD for meshes. ie in the distance replace all of the segs with really lo poly meshes.

While having LOD is a good thing, static LOD like you mention can be a bad thing, in that it increases your storage requirements (much like when generating mipmaps for textures).

Another way would be simply to implement a CLOD algorithm...it''s not really all that difficult -- using either distance or screen-space error (or both), you pick and choose which polygons should be removed. Then you simply alter the vertices. Hoppe had a lot of interesting things to say at Siggraph 96 on this. A very easy to read paper can be found at http://www.ndl.com/wpapers/clod.html.

The advantages of CLOD over SLOD (static LOD) are many, including reduced storage requirements, and much much less granular levels (veritably infinite, but not really).

Thanks for the Input Revolver,

Heres some comments, but remember I probably won''t be doing much of the programming, so this is really up to hte programmers.
Unfortunatly I have had no luck doing CLOD & making it look any good, esp with such lo-poly models already(309 Verts 466 Polys - CLOD works better with higher poly models) The space saving would be minimal, as we would just be saving mesh data for approx 3 levels. So should about double the size of the mesh data, don''t need to store the anim data, as can be extracted from the master mesh. (Remember Quake1/2/3 didn''t seem to think there was anything wrong with storing 100s of frames of mesh data for each character, we are only looking at 3)
I think I would prefer to have better control over what the Character looks like at different levels.

Cheers
Darrin

The idea is that you would simply make your models with a lot more polygons. =)

Actually, what you could do is have 3-5 different levels for the models and use each as a reference. Then when you are calculating which polygons/vertices are going to be modified, use those references as a guide...this will add a continuity in wanted appearance of the dynamic meshes. You''re basically morphing toward the next lowest "mip-model" available. Although you''re negating any storage benefits, you can eliminate popping and probably increase performance.

Also, Brian Sharp (smart guy) wrote a new article for Gamasutra/GDMag on subdivision surfaces. Definately worth a read.

Thats ok. Darrin The models are great, as I said before I was just being nit picking.. now the models you send are good, but the ones I saw in the webpage are awesome!
Really, very good quality work.
Haha however when I said armor I mean the Human Soldiers you sent me! , but dont worry about it.
Hmm.. I think I agree with revolver mixing c++ classes and c functions is probably not a good idea. I also agree that in certain cases C++ can be better for somethings like AI but I still havent meet an algorithm in c++, that cant be done by using regular c functions.
I think we should stick to regular c functions since that is what power render uses.

Hi Az,
The models you saw on the web page are actually the same models just textured & posed.
I agree the humans were pretty simplistic, am currently working on a fully textured human soldier, so will let you know when done.

Revolver, I have already read the Sub-division article, sounds pretty good eh.
Will see what our programmers want to do.
I had actually come up with a subdivision routine a while ago for terrain detail up close. Still may be able to use this for the engine?

Cheers
Darrin

When I said alienai.c/alienai.cpp I meant you use one of them not both, Or this should be more clear alienai.c or alienai.cpp . The main file will be an another one. The project will contain either alienai.cpp or alienai.c depending on whether the code is in c++ or c respectively,not both.Hope its clear now.

Well since this is a joint project different modules will be developed by different people .. so if somebody is more comfortable with c++ then c, it would give them the freedom to do so .

As far I am concerened I am more comfortable with C in PR. Maybe because it was built on it and most of the calls are C. But if somebody should develop some routines which are in C++ we should be able to use them too . Thats why the option C or C++. But if u'll want it to be in either C or C++ then I go for C.

Best Wishes,
Nat



Edited by - Nat on 4/12/00 10:19:30 PM

It was just friendly advise from a professional. I do this for a living, and can tell you that mixing can be a Bad Thing is many cases.

It''s bad for code continuity, maintinance and extensibility. Do you really plan on using those C++ particle classes John Doe just wrote in your C module? Have fun.

The whole project should use one language and stick to it...but that''s the last I''ll say on this.