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.
PR Joint Project Bits
>>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).
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).
Author
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
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.
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.
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.
Author
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
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
. 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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
