Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on August 20, 2005, 09:00:52 pm
-
(http://ferrium.org/media/pcs2_first_model.jpg)
-
:eek2: wow, that's a nice looking interface.
(though is texture#0 and #1 suposed to be under the ACEN point)
-
no - that's for noticing that - i added them to the wrong root node
there are context menus under there that will bring up the dialogs, allow you to add data [like additional path points, etc]
-
And it shows nothing...?
It wouldn't really be "loading" it then...
-
it's loaded - the renderer just isn't coded :P
-
It reminds me alot of Sugeltech, I liked it, but it was very buggy. So, it's looking very good so far.:yes:
-
God, I remember writing doing an OpenGL projection of a model a while back. I sprained several lobes of my brain. Good job, Kaz.
-
ty mik
i'm trying to decide how i want to store the tree states when resizing - because resizing you destroy the control and recreate it and that clears it's expansion and selection state - very annoying
i'm also trying to decide how to code the renderer
-
By hand. In assembly. Of course. ;)
-
rotfl
-
I settled on a method for storing and restoring the tree state.
next up is finishing the context menus
-
oh it should be noted it takes longer to open/save to pof - the internal format is NOT Pof. PCS2 has it's own internal format (that you can also save works-in-progress directly into).
This makes POF loading take longer - especially since the coordinates have to be translated into a sane [ie opengl] format
-
Kaz, while you're at it, could you please try to fix the compiling error that I always got when I tried to convert my models using your prog? The whole vertex thingamabob thing, which I think others had as well.
-
um... the error about going into infinite recursion detection?
if it's that it's a bug with your models, not with my program
-
How are you handling the infinite recursion? I've always wondered? Does PCS crash, or does it just refuse to do anything else with the model?
-
it keeps a depth tracker during the recursion to generate the BSP - if it goes over a certain value it figures "hey we're just going to keep going" - so it stocks and refuses t ocontinue [returning and error]
Fireframe rendering works - you cannot interact with the renderer yet, or render solid or textured modes - i just wanted to get the basic framework up for future work
(http://ferrium.org/media/pcs2_first_render.jpg)
-
This looks very very...practical and cool.
Will this be up for download when you're finished?
-
that's the entire point bro :D
it'll be a while - i have to get the context menus completed, then actually make all the editing dialogs, then finish the renderer
-
Awesome.
-
I'm glad to see you working on this again. I can't wait to test it :)
-
ARGH!!!!
I was going to support .max - but i cannot find documentation for the format.
If any of you can provide it
-
Originally posted by Kazan
it keeps a depth tracker during the recursion to generate the BSP - if it goes over a certain value it figures "hey we're just going to keep going" - so it stocks and refuses t ocontinue [returning and error]
In that case, you're right. Its a problem with the model. :D
You might want to consider putting in a stupidity slider to adjust the recursion limit (like a renderers ray recursion limitting). On the far left, your bog standard limit. On the far right, no limit and you were warned, you moron! That way, when the user tries to POF a model that's got coplanar and/or collocated polygons, the user can attempt to up the limit. On the far end of the limit, mind, the windows protection error that pops up will and the user will have to concede that you were right in the first place.
Or you could leave it as is. ;)
-
Originally posted by Kazan
ARGH!!!!
I was going to support .max - but i cannot find documentation for the format.
If any of you can provide it
I belive .MAX is considered off limits without a licensing fee. 3ds is probably your only option there. Could I beg and plead you to consider .LWO?
-
.3DS doesn't save the hierarchy data as Styxx and I understand it
if you can get me a very good document on the .LWO format i can add it eventually
those ****ers can kiss my ass about .max then... *******s
-
Originally posted by mikhael
By hand. In assembly. Of course. ;)
Real men use hex editors
11010111110000111010101011111110
00001101010111100000111000111010
10101010100000011111111000000111
00011111010110101010100101010101
11110000111010000011111000011110
00111110011101110110101101010111
01101001110001110011101000111001
There's your graphics renderer, Kaz. :p
-
I'm not entirely sure if this is what you are looking for, since I know absolutely nothing about programming... but it looks complicated and informative, along with containing a bunch of unintelligable jargon.
http://www.wotsit.org/search.asp?s=3d
-
If you mean the model hierarchy, .3ds either saves it or Cinema4D magically reproduces it.
-
k
-
That looks like it DragonClaw. Though I should point out that the LWO format itself changed between LW5 and 6.
-
yay!
-
http://blender.org/cms/Home.2.0.html (http://blender.org/cms/Home.2.0.html)
Go to blender.org. They do alot of stuff with Python scripts and the such so they might have what you need?
But what do I know? I build computers, not program them.
-
Boomer you must be new - you're not aware of my standing orders related to blender
Don't use that piece of monkey excrement!
it corrupts models - I will not give debugging support for any model that has been touched by blender
-
Nice work :yes:
Will the ***->POF geometry conversion routine be rewritten from scratrch or ported from older PCS versions ? Meaning is there a chance that the autofacet problems (http://www.hard-light.net/forums/index.php/topic,30243.0.html) will be adressed ?
-
it was naturally ported - but there is only one *->POF converter in PCS2 - a PMF->POF converter [PMF is PCS Model File, the format it stores it in internally.. and can write to disk] -- this makes it easier to support various model types.
-
I've only ever used blender to model my stuff - and the only times i've run into problems has been when i screw something like heirarchy up in TS. ;) All meshes i've converted with your post 1.1 versions have worked perfectly in every aspect - nothing corrupted whatsoever in about a hundred conversions so far.
'neways, the new PCS is looking good :yes: - i really like the heirarchy idea.
Questions: will it be able to:
1) Read DDS textures?
2) TGA/JPG?
3) Display glowmaps, shinemaps and environment maps?
4) Play/edit model animation scripts set up using Bobs system?
5) Auto-path all the turrets and subsystems automatically?
6) any other intended cool features? :D
-
1) If DevIL does
2) DevIL supporst them
3) Maybe eventually - but not the first release
4) Maybe eventually - but not the first release
5) That's a canonical part of the conversion process - i just ahve to translate the cob->pof code into cob->pmf
6) FOF support :D
-
On teh BSP error...
Sometimes if I convert and end result is 10 times to big, IT still works. knock it down to 2 times (like a 90meter bomber) still works. but resize down to 45 meter model and it crashes PCS (1000 BSPrecursion error) what changes in the conversion process that size matters?
Just curious if this meant the model (s) had a geometry error inherirantly or if it is a size/polly isssue.
Been trying to get a fighter/bomber in game for a while now but it won't work unless it's cruiser sized.
-
Getter Robo G: the coordinates of the polygons change in the conversion process -- it means your model has geometry errors
-
I may be wrong here, but I seem to recall PCS didn't store a default mesh size for conversion (ie if I changed it, I was unable to return it to the default value).
Only a minor gripe ofcourse though.
-
Sometimes if I convert and end result is 10 times to big, IT still works. knock it down to 2 times (like a 90meter bomber) still works. but resize down to 45 meter model and it crashes PCS (1000 BSPrecursion error) what changes in the conversion process that size matters?
I'm fairly sure that error is caused by the shrinking of the model. TS's co-ordinate system only has 3 decimal places, and so with really small objects, chances are two or more close polys are going to be merged together, thus screwing the conversion. The simple fix is to scale your ship up to the dimensions you want it to be in-game, meter to meter, and set PCS's conversion scaling factor to 1 rather than 20, basically meaning 1 TS meter equals 1 FS meter. :)
1) If DevIL does
This? http://openil.sourceforge.net/about.php
(according to that page, it does indeed support DDS, so...sweet. :cool: )
5) That's a canonical part of the conversion process - i just ahve to translate the cob->pof code into cob->pmf
An auto-convert feature? Awesomeness. :D Will it be incorporated as a feature into the path screen as well? (ie, for older models)
6) FOF support :D
FOF as in Field Of Fire? ie, a conical representation of the firing arcs of turrets. That would be....incredibly handy in preventing the dreaded shoot-through-self syndrome. :yes:
-
FOF as in Ferrium Object File :D
-
what exactly is the function for determineing the position of a polygon? is it just averageing all the points?
-
the mathematical centroid function.. here [hint: it's not a code problem]
float TotalArea=0, triarea;
vector Centroid = MakeVector(0,0,0), midpoint;
for (int i = 0; i < nverts-2; i++)
{
midpoint = Verts[verts[i].vertnum] + Verts[verts[i+1].vertnum] + Verts[verts[i+2].vertnum];
midpoint = midpoint/3;
// Area of Triangle defined by P1, P2, P3 = vector3d(crossProduct(p2-p1, p3-p1)).magnitude()/2
triarea = Magnitude(CrossProduct(Verts[verts[i+1].vertnum]-Verts[verts[i].vertnum],
Verts[verts[i+2].vertnum]-Verts[verts[i].vertnum])); // this needs to be area * 2
midpoint = triarea*midpoint;
TotalArea += triarea;
Centroid += midpoint;
}
Centroid = float(1.0 / TotalArea) * Centroid;
return Centroid;
-
it should be noted that i know for a fact now that PCS 1.0 is NOT writing the norm part of the defpoints correctly it seems because occasionally i crash both PCS 1.0 and PCS 2.0 on parsing the BSP - walking off the end of the array
-
so basicly it's a weighted (by area) average of all the average positions of all the triangles in a polygon?
what if in the case of colocated polygons you used the average position of all points as a sort of tiebreaker?
-
bobboau: no.. and it would generate incorrect geometry - i tried an colocation-detection-and-avoidance algorithm before and it didn't work.
why do you think i hate blender so much
-
Blender: an argument for commercial 3d software. (unfortunately)
-
ok, what if you triangulated one of the colocal polies? (ignoring for a moment the likely complications of this)
you could perfore this as a srt of preprocessing step
or at the least have some feature were PCS2 would highlight colocal polies
-
bobboau: then i'd end up with several colocated triangles
pcs2 could highlight colocated polygons.. but then i'd have to put a geometry editor in it for you to delete them [which i may do :P it wouldn't be incredibly difficult thanks to my using PMF for internal storage]
-
Bah. once you've hilighted them, they shouldn't have any trouble going back to the modeller and fixing things.
-
mik: yes they would - many modelers don't support selecting and deleting a single polygon very easily
-
I have trouble imagining a 3d modeller that doesn't let you get at the polys. I'm used to TS and LW, I guess.
-
bobboau please describe the auto-facet algorithm.
and everyone screw around this this build - you cannot really DO anything with it - but you can load models, move them around in the geometry viewer - look at the tree
Current Todo List:
- Finish context Menus
- Create Program Preferences menu - including texture paths
- Implement texture loader
- Implement standard editor windows
- Implement PMF::LoadFromCOB
- Implement PMF::SaveToCOB
- Impelement Geometry Editor
-
Oooh, nifty. :) It does indeed take a while to load models - perhaps some sort of loading bar would be appropriate to show that it hasn't in fact locked up?
Oh, one very minor thing is that the open cob file stub is apparently broken - delivers the 'not yet implemented' message, but then crashes.
Lastly, what's the (/is there yet a) zoom control?
Looking good so far. Can't wait for the final thing. :D
Blender: an argument for commercial 3d software. (unfortunately)
Bah, it can do everything the big'uns can, and has only ever crashed twice for me. TS on the other hand..... :p
-
Originally posted by Vasudan Admiral
Oooh, nifty. :) It does indeed take a while to load models - perhaps some sort of loading bar would be appropriate to show that it hasn't in fact locked up?
i already planned that - forgot to put it in the TODO list above
I think a lot of the bottleneck is std::vector so i'm going to code my own dynamic-array class
Oh, one very minor thing is that the open cob file stub is apparently broken - delivers the 'not yet implemented' message, but then crashes.
thanks :D
Lastly, what's the (/is there yet a) zoom control?
Looking good so far. Can't wait for the final thing. :D
just like PCS press shift and you move the ship instead of rotating it - remember both mouse keys control different axis
Bah, it can do everything the big'uns can, and has only ever crashed twice for me. TS on the other hand..... :p
hehe - blender doesn't crash itself - it just crashes other applications because the truely nasty output is
-
auto-facet normal generation:
if a poly has a material that is flaged as being auto-faceted, then the normal of each point on that polygon is the average of the normals of all polies useing that point that have a diference in angle less than or equal to the facet angle when compared to the normal of the source poly
-
k bobboau - i'm going to have to upgrade "textures" to "materials" in PMF and save that additional information
WARNING: Only save 'builds' to POF - Keep your working copies as PMFs for both performance issues and because until i can fix my BSP compilers DEFPOINTS generator i will not import point-normals from POF [just face normals
-
It opens most of my BWO .pof's. That's all I needed it to do really. Awesomeage.
Can't wait for newer versions.
-
what POFs does it crash on?
[edit]
i need them for testing
-
They're unreleased and secret - don't think I can share unless you can get a unanimous permission from IceFire and Ace and Bobbau, since they've worked on the stuff.
It times out on the HTL Golgotha (maybe my fault, waited for 10min though), it crashes on the normal Golgotha (Windows gives me the "send details to us for better spying" crap). Same for Charon. Some other files, it just simply doesn't recognise (don't know why).
Hmm. Doesn't recognise the HTL Erinyes and some BWO .pof's as well, weird that.
But it works on most of my BWO stuff, cruisers, bombers, fighters, etc.
-
ok - the golgotha issue probably is just it taking ages - hopefully what i'm going to do next solves that
the crashing ones i need though
-
Ask the trio, maybe they give it to you. I don't really hold any authority with the stuff, until told otherwise.
-
well replacing std::vector and std::string with my own replacements didn't really speed things up - but it does make debugging a lot easier :D
-
it didn't speed things up, but it did reduce the memory usage significantly [it was using up 34megs the other day when a capship from wcs was loaded]
-
i've located the bottleneck PMF::LoadFromPOF to be entirely the subobjects
-
if I were you I'd make my own array class, though I beleive most of the slow down with std::vector is in debug mode and it goes away in release.
-
yeah i wrote my own vector and string [the string actually inherits a kaz_vector as a parent class :P]
I've located the bottleneck to be the geometry translation and i have an idea in how to speed it up
-
holy mother of optimizations :D
I made it load POFs [translating a POF to PMF] almost as fast as PCS 1.x can load a POF
i changed the manner in which it parses the BSP
play with the attached version :D
-
That's odd. It seems to crash upon trying to load 90% of the [v] ships. It spits out the message 'You have selected a non-supported file format' and then crashes completely. Out of all the [v] ships, it only works on the medusa, ursa, osiris, nephilim, (cargos 01, 03, 04, 05, 06), shivan gas miner, anuket, alastor and the terran support ship(looks like its the FS1 version, not the hygeria).
Every other [v] ship crashes it, and i don't see a pattern. :\
It does however now load even HTL ships like the fenris almost instantaneously, so thats cool. :D
hehe - blender doesn't crash itself - it just crashes other applications because the truely nasty output is
Nasty output? It exports dxf - there isn't a lot that can go wrong there, unless the user creates dogey geometry (blender makes no attempt to fix it - it just assumes you know what you're doing). ;)
Oh yes, and it has it's own source code project, so chances are whatever it is that caused problems originally has been fixed by now. :)
-
vasudan: the geometry blender outputs is nasty
"You have selected a non-support file format" only occurs if
strtr(filename, ".pmf") == NULL
strtr(filename, ".pof") == NULL
strtr(filename, ".cob") == NULL
strtr(filename, ".fof") == NULL
[checks are done in that order]
[edit] ok .. i can reproduce that bug.. OH i think i know what it is... grr
i'm using a case-sensative string check.. bleh mesa stupid
-
lol, yep, there's the pattern. Good to know it wasn't serious. :)
One small request though, could you get the open file screen to default to .pof or even better, an 'all supported formats'? That'd be cool. :)
And what exactly is nasty about blenders dxf's? I really have never encountered a problem in 3-4 years of usage, and for the past year, these have include some extremely complex models. In fact, when a PCS conversion crash is caused by a geometry error, it's always a model that i attempted to make using only TS. ;)
-
blender outputted nasty polydata - that was it's problem
if it could find a way to break the BSP constraints it would
-
nevermind
-
Hmm, after looking it up on the blender forums, it appears that in older versions, if boolean operations were used it could cause BSP problems in various games due to a 'cheesy original implementation'. It's been fixed in the more recent versions, but it's not really a problem in general anyway because you rarely if ever need to use bools.
However, i can see how it would be an easy thing to do if you were used to using bools in other modelers, and were using an old version. ;)
Either way, it works now, and so if you model stuff right, blender'll output it right. :)
-
you should be using booleans to reduce polygons counts a lot
-
For the sorts of modeling i do and what blender is suited to, they'd have the exact opposite effect i'm afraid. :)
-
i still don't trust blender farther than i can throw a car - it remains on my blacklist
-
Well, as long as you don't code anything in that would hunt down blender models and crash on them (how that would work i don't know, but meh :D ), i highly doubt you'll get any complaints that come because of blender. If you do tho, defer them to me, and i'll take a look into it. :)
-
just tested it out, it took me a while to find a model that would load, but when it did I must say, new renderer++. defenately a step in the right direction. though there seems to be a minor issure with lighting and scaleing.
are any of the editing capabilities ready? I selected edit on just about everything and nothing poped up, didn't know if they were ready or not yet. how are the edit windows going to be implemented? it seems to me like the best thing to do would be to have the lower portion of the screen become an edit pane. and what of drag and drop capabilities? can/will items of the same type be move/copied from one place to another (one missle point from one bank to another one vector from one section to another)? and what ever you do, don't forget to add a 'copy' comand to everything. as you are implementing stuff, you should put int new, delete copy. copy is ten times as useful as new.
once you get the basic editing capabilities done, might I sudgest you implement a ray picker, would make selecting and placeing of stuff much easier.
-
Will there be a linux build soon? :D
-
he's codeing it in wx so probly.
-
wmc: grab it from cvs and compile
i don't release linux binaries
-
no bob.. they're not implemented - if you would have looked at my TODO you would have noticed that :P
-
ah... yes but why would I avoid waisting both of or time like that?
so what about a ray picker(clik on the screen and it selects the part of the modelyou click on)? there actualy a lot easier to implement than you might think. although if you'r implementig a geometry editor then you will basicly have to.
-
bobboau: i can also allow selecting polygons from a dialog that lists them :P
bob.. if you want i'll give you CVS write access and you can help with the 3D stuff
when the ray picker is active it'll be ctrl+Lclick
-
Well the newer version seems to open more of them.
The 10min wait for the HTL Golgotha (and didn't open) now took approx 3 seconds. Also the Erinyes loaded instantly.
Woot.
-
BlackDove:
Early versions would go through the BSP tree and copy all it's data into lists then translate them - the new one is an adaptation of my BSP renderer: which walks the tree instead -- less memory allocations, less memory usage and obviously much faster because of - not to mention it only moves data once instead of twice
oh.. and it cleanly imports the point normals :D
new system
code segment one (with old translation system commented out)
// --------- Sub object Consversion ---------
subobjects.resize(poffile.OBJ2_Count());
pcs_sobj *obj;
int type, bspsz;
unsigned int used_polygons;
char *bspdata;
BSP bspparser;
BSP_DefPoints points;
for (i = 0; i < poffile.OBJ2_Count(); i++)
{
obj = &subobjects[i];
poffile.OBJ2_Get_Parent(i, obj->parent_sobj);
poffile.OBJ2_Get_Radius(i, obj->radius);
poffile.OBJ2_Get_Offset(i, obj->offset);
obj->offset = POFTranslate(obj->offset);
poffile.OBJ2_Get_GeoCenter(i, obj->geometric_center);
obj->geometric_center = POFTranslate(obj->geometric_center);
poffile.OBJ2_Get_BoundingMin(i, obj->bounding_box_min_point);
obj->bounding_box_min_point = POFTranslate(obj->bounding_box_min_point);
poffile.OBJ2_Get_BoundingMax(i, obj->bounding_box_max_point);
obj->bounding_box_max_point = POFTranslate(obj->bounding_box_max_point);
poffile.OBJ2_Get_Name(i, obj->name);
poffile.OBJ2_Get_Props(i, obj->properties);
poffile.OBJ2_Get_MoveType(i, type); // -1 = none, 1 = rotate
switch (type)
{
case 1:
obj->movement_type = ROTATE;
break;
default:
obj->movement_type = MNONE;
}
poffile.OBJ2_Get_MoveAxis(i, type); // -1 = none, 1 = X, 2 = Z, 3 = Y
switch (type)
{
case 1:
obj->movement_axis = MV_X;
break;
case 2:
obj->movement_axis = MV_Z;
break;
case 3:
obj->movement_axis = MV_Y;
break;
default:
obj->movement_axis = ANONE;
}
// -------------------------------- fast method --------------------------------
poffile.OBJ2_Get_BSPDataPtr(i, bspsz, bspdata);
obj->polygons.resize(100); // good starting size;
used_polygons = 0;
BSPTransPMF(0, (unsigned char *) bspdata, points, obj->polygons, used_polygons);
obj->polygons.resize(used_polygons); // resize to exact size
/* // -------------------------------- slow method --------------------------------
poffile.OBJ2_Get_BSPData(i, bspsz, bspdata);
bspparser.DataIn(bspdata, bspsz);
obj->polygons.resize(bspparser.Count_FlatPolys() + bspparser.Count_TmapPolys());
k = bspparser.Count_FlatPolys();
for (m = 0; m < k; m++)
{
obj->polygons[m].texture_id = -1;
obj->polygons[m].norm = POFTranslate(bspparser.fpolys[m].normal);
obj->polygons[m].verts.resize(bspparser.fpolys[m].nverts);
for (j = 0; j < bspparser.fpolys[m].nverts; j++)
{
l = bspparser.fpolys[m].verts[j].vertnum;
obj->polygons[m].verts[j].point = POFTranslate(bspparser.points[0].vertex_data[l].vertex);
// i'm stll having problems with norms.. which means i've still been writing
// the BSP::Points incorrectly in the latest version of PCS 1.x -- /sigh
obj->polygons[m].verts[j].norm = vector3d(0,0,0);
//obj->polygons[m].verts[j].norm = POFTranslate(bspparser.points[0].vertex_data[l].norms[bspparser.fpolys[m].verts[j].normnum]);
}
}
for (m = 0; m < bspparser.Count_TmapPolys(); m++)
{
obj->polygons[m+k].texture_id = bspparser.tpolys[m].tmap_num;
obj->polygons[m+k].norm = POFTranslate(bspparser.tpolys[m].normal);
obj->polygons[m+k].verts.resize(bspparser.tpolys[m].nverts);
for (j = 0; j < bspparser.tpolys[m].nverts; j++)
{
l = bspparser.tpolys[m].verts[j].vertnum;
obj->polygons[m+k].verts[j].point = POFTranslate(bspparser.points[0].vertex_data[l].vertex);
// i'm stll having problems with norms.. which means i've still been writing
// the BSP::Points incorrectly in the latest version of PCS 1.x -- /sigh
obj->polygons[m+k].verts[j].norm = vector3d(0,0,0);
//obj->polygons[m+k].verts[j].norm = POFTranslate(bspparser.points[0].vertex_data[l].norms[bspparser.tpolys[m].verts[j].normnum]);
obj->polygons[m+k].verts[j].u = bspparser.tpolys[m].verts[j].u;
obj->polygons[m+k].verts[j].v = bspparser.tpolys[m].verts[j].v;
}
}
bspparser.Reset();
delete[] bspdata;*/
}
return true;
}
the walker
//****************************************************************************
// DIRTY BSP FUNCTIONS - DON'T READ OR YOU'LL HURT YOUR EYES! AAAARGGGGGHHHHHH
// PARSING
//****************************************************************************
void BSPTransPMF(unsigned int offset, unsigned char *data,
BSP_DefPoints &points, kaz_vector &polygons,
unsigned int &upolys)
{
BSP_BlockHeader blkhdr;
unsigned char *curpos = data + offset;
//BSP_BoundBox *bbox;
blkhdr.Read((char *) curpos);
switch (blkhdr.id)
{
case 0: // End of Tree
break;
case 1: // DEFPOINTS
points.Read((char *) curpos + blkhdr.MySize(), blkhdr); // interpret block
BSPTransPMF(offset + blkhdr.size, data, points, polygons, upolys); // continue traversal
break;
case 2: // Untextured Poly
TranslateFPoly(offset, data, points, polygons, upolys); // interpret and continue
break;
case 3: // Textured Poly
TranslateTPoly(offset, data, points, polygons, upolys); // interpret and continue
break;
case 4: // Sortnorm
InterpretSortNorm(offset, data, points, polygons, upolys); // interpret and continue
break;
case 5: //boundbox
BSPTransPMF(offset + blkhdr.size, data, points, polygons, upolys); // continue traversal
break;
default:
break;
}
}
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
void TranslateFPoly(unsigned int offset, unsigned char *data,
BSP_DefPoints &points, kaz_vector &polygons,
unsigned int &upolys)
{
BSP_BlockHeader blkhdr;
unsigned char *curpos = data + offset;
blkhdr.Read((char *) curpos);
vector3d point, norm;
int vertex_offset = 0;
pcs_polygon temp_poly;
BSP_FlatPoly fpoly;
fpoly.Read((char *) curpos + blkhdr.MySize(), blkhdr);
temp_poly.norm = POFTranslate(fpoly.normal);
temp_poly.texture_id = -1;
temp_poly.verts.resize(fpoly.nverts);
for (int i = 0; i < fpoly.nverts; i++)
{
temp_poly.verts[i].point = POFTranslate(points.vertex_data[fpoly.verts[i].vertnum].vertex);
vertex_offset = 0;
for (int j = 0; j < fpoly.verts[i].vertnum; j++)
{
vertex_offset += points.norm_counts[j];
}
temp_poly.verts[i].norm = POFTranslate(points.vertex_data[fpoly.verts[i].vertnum].norms[fpoly.verts[i].normnum-vertex_offset]);
temp_poly.verts[i].u = 0;
temp_poly.verts[i].v = 0;
}
if (upolys >= polygons.size())
{
polygons.resize(polygons.size() * 2);
}
polygons[upolys] = temp_poly;
upolys++;
fpoly.Destroy();
BSPTransPMF(offset + blkhdr.size, data, points, polygons, upolys); // continue traversal
}
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
void TranslateTPoly(unsigned int offset, unsigned char *data,
BSP_DefPoints &points, kaz_vector &polygons,
unsigned int &upolys)
{
BSP_BlockHeader blkhdr;
unsigned char *curpos = data + offset;
blkhdr.Read((char *) curpos);
int vertex_offset = 0;
vector3d point, norm;
BSP_TmapPoly tpoly;
pcs_polygon temp_poly;
tpoly.Read((char *) curpos + blkhdr.MySize(), blkhdr);
// 2^32-1 = 4294967295
// 2^8-1 = 255
temp_poly.norm = POFTranslate(tpoly.normal);
temp_poly.texture_id = tpoly.tmap_num;
temp_poly.verts.resize(tpoly.nverts);
//norm = tpoly.normal
for (int i = 0; i < tpoly.nverts; i++)
{
temp_poly.verts[i].point = POFTranslate(points.vertex_data[tpoly.verts[i].vertnum].vertex);
//protecting ourselves from whacky norm numbers, *shrug* don't know where they're coming from
vertex_offset = 0;
for (int j = 0; j < tpoly.verts[i].vertnum; j++)
{
vertex_offset += points.norm_counts[j];
}
temp_poly.verts[i].norm = POFTranslate(points.vertex_data[tpoly.verts[i].vertnum].norms[tpoly.verts[i].normnum-vertex_offset]);
temp_poly.verts[i].u = tpoly.verts[i].u;
temp_poly.verts[i].v = 1-tpoly.verts[i].v;
}
tpoly.Destroy();
if (upolys >= polygons.size())
{
polygons.resize(polygons.size() * 2);
}
polygons[upolys] = temp_poly;
upolys++;
BSPTransPMF(offset + blkhdr.size, data, points, polygons, upolys); // continue traversal
}
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
void InterpretSortNorm(unsigned int offset, unsigned char *data,
BSP_DefPoints &points, kaz_vector &polygons,
unsigned int &upolys)
{
BSP_BlockHeader blkhdr;
BSP_SortNorm snorm;
unsigned char *curpos = data + offset;
blkhdr.Read((char *) curpos);
snorm.Read((char *) curpos + blkhdr.MySize(), blkhdr);
if (snorm.front_offset)
BSPTransPMF(offset + snorm.front_offset, data, points, polygons, upolys); // continue traversal
if (snorm.back_offset)
BSPTransPMF(offset + snorm.back_offset, data, points, polygons, upolys); // continue traversal
if (snorm.prelist_offset)
BSPTransPMF(offset + snorm.prelist_offset, data, points, polygons, upolys); // continue traversal
if (snorm.postlist_offset)
BSPTransPMF(offset + snorm.postlist_offset, data, points, polygons, upolys); // continue traversal
if (snorm.online_offset)
BSPTransPMF(offset + snorm.online_offset, data, points, polygons, upolys); // continue traversal
// No tail recursion on sortnorms
}
-
Originally posted by Kazan
Boomer you must be new - you're not aware of my standing orders related to blender
Don't use that piece of monkey excrement!
it corrupts models - I will not give debugging support for any model that has been touched by blender
[defensive] I wouldn't necessarily consider myself new since I read every thread in the damn forum before registering which put me off a few months[\defensive]
And I wouldn't dismiss blender so easily. You obviously haven't looked at some of the python scripts such as *cough* Truespace .COB import\export *cough* or the built in UVunwrapper, the mesh cleaning tools... Plus, it can import\export most common 3d object files including .3ds if you get the script.
And, honestly, have you even tried the newer versions of Blender? Hmmmm? It's free it makes models, and it exports them to .COB, and it's even free. if you avoid dxf's no corruption occurs. So if you want to badmouth blender, fine, but Blender works a hell of a lot better for me than f****** GMAX did.
I'm just sorry it took so long for me to reply to disprove this vile slander against blender. I've been working on some new ships for my new campaign so I haven't checked here for a while.
-
Boomer: i didn't dismiss Blender so easily - i dismissed if after 99% of people complaining "bugs" to me in PCS 1.x was there bad model data created by blender for about 6 months
-
And how long ago was that?
-
Calm down Boom. ;) Read my posts a couple up from here - it seems that there was indeed a BSP error or somesuch in the pre-source code versions, and it caused problems with importing meshes into other games.
It has since been fixed, but i can well imagine how people back then would automatically assume that the reason for their model not working was PCS, since that'd be where the crash would occur - and thus likely giving Kaz quite a headache with bugsupport and tracking. And if that occured for 6 months as he says, you really can't blame him for distrusting the real cause. ;)
The most effective argument for modern blender is not to argue, but just go and build really cool stuff with it to prove how far it's come. :)
-
if it doesn't give you problems then you never have to come to me admitting "i used blender on this model" and we're both happy :P
-
PCS2 alpha? NICE! :)
A small feature request: I'd like to have rotate/move buttons like in modelview, if this would be possible one day (I, errm, used them for making techanis (ok, ok - only one so far) ... - yes, I know they're not needed anymore, but I still like them).
And about Blender: I built my first 3,5 models with it, the first two having clipping issues in FS and the other 1,5 simply not converting at all (completely rebuilt them with tS later on).
But that was in 2001/2002 so possibly that's all solved by now - on the other hand, by now I've gotten used to use tS... ;)
-
i was going to put buttons in there.. but it looked kinda ugly.. i'll try doing a toolbar again and see how that looks
-
Originally posted by Kazan
wmc: grab it from cvs and compile
i don't release linux binaries
kaz_templates.h:51: error: ISO C++ forbids declaration of ‘operator=’ with no type
kaz_templates.h:75: error: ISO C++ forbids declaration of ‘operator=’ with no type
wxCTreeCtrl.h:73: error: ISO C++ forbids declaration of ‘operator=’ with no type
wxCTreeCtrl.h:78: error: ISO C++ forbids declaration of ‘operator=’ with no type
wxCTreeCtrl.h:86: error: ISO C++ forbids declaration of ‘operator==’ with no type
wxCTreeCtrl.h:91: error: ISO C++ forbids declaration of ‘operator==’ with no type
-
um....
slutty MSVC
cvs update and it's corrected
[pst: use your IM services j00 slut!]
-
here the context menus are finished.. play :D
-
It opens everything I throw at it, except the Charon. :p
-
i need that model to see what is causing the crash
-
Looking excellent Kazan :)
You mentioned that you might add .LWO if you can find a description of the format..
http://www.newtek.com/products/lightwave/developer/LW80/8lwsdk/docs/filefmts/lwo2.html
Does that help?
-
wtfh ... lwo uses mac byte order
-
Actually it uses Amiga byte order. :D
Remember where it started? :)
-
Hmm, ability to zoom in close to model (especailly for large ones) would be great.
Also should it be a concern that some .pofs I converted with PCS 1,4,? and DO work in game won't open in PCS2?
On the plus side it DID open the nearly 4k Death Glider I just converted and some building sets I was planning on converting fully (5k)
Interesting it opened all the 8k Gundams but crashed on the 1k Core fighter...
Kazan do you want me to send you some of these working .pofs to see if you can notice why PCS1 made them ok but they don't open in PCS2?
Also is .cob opening going to be enabled soon?
-
Originally posted by Getter Robo G
Hmm, ability to zoom in close to model (especailly for large ones) would be great.
Zoom is already there - press shift while right-mouse dragging vertically with
Originally posted by Getter Robo G
Also should it be a concern that some .pofs I converted with PCS 1,4,? and DO work in game won't open in PCS2?
yes, and i need to know what models they are and i must have the files
unlike MR BWO member telling me about bugs then not ****ing helping me solve them by giving me the offending files
Originally posted by Getter Robo G
On the plus side it DID open the nearly 4k Death Glider I just converted and some building sets I was planning on converting fully (5k)
cool
Originally posted by Getter Robo G
Interesting it opened all the 8k Gundams but crashed on the 1k Core fighter...
I don't think the bugs that are causing load crashing are in the geometry load - i need the file that fails
Originally posted by Getter Robo G
Kazan do you want me to send you some of these working .pofs to see if you can notice why PCS1 made them ok but they don't open in PCS2?
I just need the broken ones
Originally posted by Getter Robo G
Also is .cob opening going to be enabled soon?
after i create the preferences menu and get textures loading
i haven't even started writing the COB->PMF and PMF->COB functions yet
-
er, in case I missed it WHERE do I send'em to? ;)
-
Originally posted by Kazan
unlike MR BWO member telling me about bugs then not ****ing helping me solve them by giving me the offending files
Must ask Bobby :p
-
getter you can PM me locations or send them to thekazan AT gmail DOT com
-
just finished the configuration menu
next up is texture loading
-
Bless you, Flipside. :D
-
hehe.. with all the nasty **** i'm going to have to do for LWO support it's going to probably be the last file format I implement before i release 1.0
file formats to implement support for before 1.0
.cob
.3ds
.lwo
-
wtf.. ilLoadL(ILenum type, char *buffer, int size) is failing loading some of the fenris textures... but it's not setting an error code.. *funny look*
-
upgrading to the latest DevIL libraries fixed that.. it's loading the textures.. but my texcoords are fuqed
ok.. my texture coordinates aren't fuqed.. it's having problems either in ilLoadL or in it's PCX support.. investigating further..
-
are they getting rescaled to 2^n? useing almost any FS1 era ship will requier takeing this into acount.
-
do i have to rescale all to 2^n?
-
ohyes.
they don't have to be square, take the dimentions, if one or more is not power of 2 rase it/them to the next largest power of two and resize.
-
making it scale them fixed it
iluGetImageInfo(&imginfo);
sz = (imginfo.Width > imginfo.Height)?imginfo.Width:imginfo.Height;
iluScale(sz, sz, imginfo.Depth);
thanks bro!
-
here comes a build that supports textures!
the default texture path is
c:\games\freespace2\
you must setup a texture path for EACH mod
my texture paths look like this
d:\games\freespace2\
d:\games\freespace2\wcsaga\
d:\games\freespace2\fsport\
d:\games\babylon5\
d:\games\Wing Commander Saga\
-
Hehe, crash when I want to resize the window. Any model.
-
since posting that build i fixed a crashing bug related to the POF file having zero PINF strings [load the Charon in 1.x and check if it has zero strings BlackDove, if that is it then right there is why it was crashing]
[edit]
Crashing on resize? odd.. doesn't do that to me. When the window resizes the controls [tree, and model view] are destroyed and recreated - which means it reloads the textures
-
I said they _don't_ have to be square, though that will get the job done, this is more what I meant.
iluGetImageInfo(&imginfo);
sx = imginfo.Width;
sy = imginfo.Height;
float b = log(sx)/log(2);
if(b - (int b) > 0)sx =pow(2,int(b)+1);
b = log(sy)/log(2);
if(b - (int b) > 0)sy =pow(2,int(b)+1);
iluScale(sx, sy, imginfo.Depth);
I'm prety sure that does what I think.
although now that I think about it some bitshifting could probly be done to speed that up.
-
Originally posted by Kazan
since posting that build i fixed a crashing bug related to the POF file having zero PINF strings [load the Charon in 1.x and check if it has zero strings BlackDove, if that is it then right there is why it was crashing]
Charon won't load at all. But that's beside the point really. I maybe don't have the textures proper and the paths done as you said, considering I didn't understand what I'm supposed to do with em.
-
PCS 1.x won't load the charon? then how did you convert it :P
-
I've been testing out some TBP models with it. The B5 model and Ja'Stat models cause it to CTD. While *another* model causes a windows error and crash. Same with Hyperion model. The Midwinter model resulted in this error:
The instruction at "0x0d5f15e0" referenced memory at "0x00000004". The memory could not be "read".
My second time trying the Midwinter resulted in a simple crash error. Same for Omega, but the OmegaX openned fine. The Shadow craft, the Shn'Tan, Zephyr, and the Th'Nor have no textures displayed at all. The Vorchan merely lacks textures on the multi-part twin-barrel turrets, while the Avioki only has textures on its pylons and nowhere else. Any jumpgate, whether it be EA or Narn, single arm or pre-configured, all cause a crash error.
-
Don't ask me dude, I just try to open the thing and I tell you if it works or doesn't :p
-
OK tp.. ill try and load b5 with her
-
TP: are the missing textures animated textures?
one crash source located on B5... she crashes after trying to render the first time.. trying to locate that crash now
two crash bugs fixed thanks to b5.. but she freaks the lighting system out :D
[edit again]
oh meng.. it's not flipping out the lighting system - DDS textures are generating an IL_INVALID_FILE_HEADER error..
[edit yet again]
yep... size2 != 32.. hrm.. /sigh.
DDS support = null then
nope... Paint Shop Pro 9 won't open those DDS files either... something is wrong with them
-
man-oh-man bsp generation is shot... this is going to be a nightmare to debug.. an absolute nightmare.
i may just rewrite it from scratch possible if i can understand the data enough.
-
ok i don't have to make sense of prelist, postlie and online - they never put anything on them.. sweet :D
so it really is a binary tree
oh.. and kiss flatpolygons goodbye
-
pre list and post list I can understand, but they didn't use the on list!?! is that even posable?
oh and goodbie flat polies, you won't be missed.
-
explain prelist and post list - the only list being used by either V's generator or my origional one was the front list and back list
[edit]
get on ICQ! :D
-
I mean I can understand them not being used, isn't the on list needed the pollies that get intersected by the split plane.
I don't have IQC installed currently, and I'm planning on sleeping soon
-
ok.. i think i can handle this (only one poly should be in the "onlist" from what i have read and that is the poly you use to postion the list if you choose so - otherwise you should "cut" the polygon in two and place one half on each side)
-
"You got GMail Kazan!"
I sent ya like 5-6 .pofs that I made screensots of in game and that work just fine. Some were made with pcs1, I bet other were made with modelview or high poly pof2 cob (not sure cant rememebr but if you need more later I do have lots of pcs1 only models to send you).
I figure if you can see how other ones were converted maybe it will spark something.
Anyway how about a remember size window feature so I dont have to resize teh window each time I opena model while the program is running? Also teh NEW button doesn;t erase teh current loaded one. Will you add a support for glow maps so you can see what teh final model will look like in game? L8tr!
-
i'm doing calculus at 3am - somebody shoot me :D
-
*StratComm pulls out rifle*
Glad I'm not the only one up late :p
BTW, you should look in the Ferrium internal when you get a chance.
-
once i get done with the calculus of this method of BSP splitting and make it work it should be more difficult to send her into infinite recursion - because then it will take literally two copys of the same polygon to set her off
-
It needs geomodding!!! :p
-
rotfl
cutting a polygon with a plane is bad enough
-
hey bob.. check my code
Requires: polygon to actually be bisected by plane
Expects: polygons to be a triangulated mesh
void SplitPolygon(kaz_vector &polygons, int polynum, vector3d plane_point, vector3d plane_normal)
{
kaz_vector splitpolys(2); // 0 = front vert, 1 = back vert
kez_vector pairs;
kaz_vector points;
pairs.resize(polygons[polynum].verts.size() * 2);
pcs_vertex temp;
int i, j = 0;;
float uvdelta;
// using a pairs list cuts down on having a special-case
for (i = 0; i < polygons[polynum].verts.size() * 2; i += 2)
{
pairs[i] = j % polygons[polynum].verts.size();
pairs[i+1] = j+1 % polygons[polynum].verts.size();
j++;
}
// compile the new list of points
for (i = 0; i < pairs.size(); i += 2)
{
if (DistanceToPlane(polygons[polynum].verts[pairs[i]].point, plane_point, plane_normal) == 0.0
|| DistanceToPlane(polygons[polynum].verts[pairs[i+1]].point, plane_point, plane_normal) == 0.0 )
// one of these points lays on the plane... add them both without modification
{
AddIfNotInList(points, polygons[polynum].verts[pairs[i]]);
AddIfNotInList(points, polygons[polynum].verts[pairs[i+1]]);
}
else // neither of them was not on the plane.. are they on the same side?
{
if (InFrontofPlane(polygons[polynum].verts[pairs[i]].point, plane_point, plane_normal) ==
InFrontofPlane(polygons[polynum].verts[pairs[i+1]].point, plane_point, plane_normal))
// both on same side - add them
{
AddIfNotInList(points, polygons[polynum].verts[pairs[i]].point);
AddIfNotInList(points, polygons[polynum].verts[pairs[i+1]].point);
}
else
// different sides - cut and add
{
uvdelta = FindIntersection(temp.point, polygons[polynum].verts[pairs[i]].point,
polygons[polynum].verts[pairs[i+1]].point, plane_point, plane_normal);
temp.norm = polygons[polynum].norm;
temp.u = uvdelta * (polygons[polynum].verts[pairs[i]].u - polygons[polynum].verts[pairs[i-1]].u);
temp.v = uvdelta * (polygons[polynum].verts[pairs[i]].v - polygons[polynum].verts[pairs[i-1]].v);
AddIfNotInList(points, polygons[polynum].verts[pairs[i]]);
AddIfNotInList(points, temp);
AddIfNotInList(points, polygons[polynum].verts[pairs[i+1]]);
}
}
}
// split the polygons with the list we have
int in = 0;
for (i = 0; i < points.size(); i++)
{
if (DistanceToPlane(points[i].point, plane_point, plane_normal))
// there WILL be two points in the list this is true for
{
AddIfNotInList(splitpolys[0].verts, points[i]);
AddIfNotInList(splitpolys[1].verts, points[i]);
if (in == 0)
in = 1;
else
in = 0;
}
else
{
AddIfNotInList(splitpolys[in].verts, points[i]);
}
}
// triangle our new polylist
TriangulateMesh(splitpolys);
// replace our current poly with polygon zero - add the others
polygons[polynum] = splitpolys[0];
in = polygons.size();
polygons.resize(in+splitpolys.size()-1);
for (i = 1; i < splitpolys.size(); i++)
{
polygons[in+i] = splitpolys[i];
}
}
-
Jumps in front of the field of fire "NOooooooooo!" (Vader Voice)
He's not DONE yet, plus he has to finish Ferrium next!!! (Gose for the Force choke and then rememebrs he is NOT a Sith Lord)...
"Hmmm.... Here's my hand, now CHOKE YOURSELF private!" :D
-
oh getter.. gmail blocked your email.. but don't worry about it - see if the next version i release fixes the bugs
-
holy crap.. i'm hitting polygons where the magnitude of the cross product of the two lefts of the polygon is ZERO!!!!!
wtfh!
-
oh man.. it's a rounding error due to the precision of float
-
not completly sure if splitting the poly is needed (or wise) but the basic algorithm should be basicly
have two output polies, and one input poly
start at the first point in the input poly,
check the distance from the plane, if it's positive put it into the first output poly, if negitive the second, if the next point is not on the same side of the plane find the point on the line segment that intersects the plane and add that point to both lists, do this for each point untill all points are done.
(if applicable)remove the input poly from what ever list it's in and replace it with the two output polies.
or at least that's the way I always do it.
models should not be triangulated, in fact it might be worth the effort to add code that finds polies that can be untriangulated (this would be more messy than it first seams because you'd need to make sure the texture space would be uniform across all of them).
untriangulated models do faster colision detection.
-
the splitting code is commented out now.. it was causing problems.
I have rewritten the BSP generator completely from scratch and i'm debugging the flaws in the output right now
-
I would recomend just putting the intersected polys (or should I say the sortnorms that lead to polys on the split plane) on the onlist, that's probly what I'd do if writeing the BSP generator myself.
currently the BSP isn't used at all (I tryed to use them in decals, but I don't think it does any good, and in a while this'll get changed), in the not to distant future this will probly change, but it won't need to be 100% acurate. if it's used for poly sorting for front to back and back to front rendering it won't realy be that bad most of the time if it isn't absolutely perfict.
the only thing that the sortnorm chunck gets is
if (!mc_ray_boundingbox( vp(p+56), vp(p+68), &Mc_p0, &Mc_direction, NULL )) {
return;
}
in model colide, everything else just skips on through pre->front->on->back->post without doing any checking
and as far as I have been able to tell the only thing the pre and postlists do is specify sections of the BSP that should be processed before the current one, no idea why this would be done, but it is, and it seems like they are used.
and you do know of POFdview, yes? it would probly come in REALY handy trying to reverse engeneer V's BSP ideas.
-
i have it writing a BSP tree that PCS 1.x and 2.x will both read.. modelview and fs2open refuse to load it - fs2 open gave me a malloc failure.. but having two MSDEVs open and one huge app in the debugger caused my puter to freak out.. reboting it right now as i type
-
ooh.. it's crashing in the IBX generator...
-
it shoots the smooth phong shading all the hell... but the new models will load in model view and fs2 open
it think it's just associating the wrong normals...
apparently the BSP walker in fs2_open and in modelview are kinda flakey -- they're iterating across the tree instead of recursing on it - mine was the only one implemented prperly according to the theory - inserting some extra terminators into the data fixed that up.
-
Originally posted by Kazan
rebooting right now as i type
:lol:apparently the BSP walker in fs2_open and in modelview are kinda flakey -- they're iterating across the tree instead of recursing on it - mine was the only one implemented prperly according to the theory - inserting some extra terminators into the data fixed that up.
Is it possible that yours is the only one not implemented properly?
And incidentally, you don't need to make 10 posts in a row to give hour-by-hour updates. Editing is A-1 SUPAR.
-
you know that the normal indecies are for the total list of them, not the per vert list, as stupid as that is.
-
Originally posted by Goober5000
:lol:Is it possible that yours is the only one not implemented properly?
yes and i got out the POF BSP/IDTA specs and a reference on BSP theory and found mine was right and that the new IBX one in the game along with the Modelview ones are wrong.
making them work is simply a matter of using the prelist_offset to immediately shove a BSP::EOF right after the sort norm so that they terminate looping
-
Originally posted by Bobboau
you know that the normal indecies are for the total list of them, not the per vert list, as stupid as that is.
yeah.. i know.. but it was still not coming up right..... *plays with the code again*
[edit]
code blocks unneeded.. FIXED
-
i submit this image for p1mpage
(http://www.ferrium.org/media/pcs-alpha-20050828.jpg)
Current Todo List:
- Implement Progress Bars for loading/saving
- Implement Error Messages for loading/saving
- Implement standard editor windows
- Implement PMF::LoadFromCOB
- Implement PMF::SaveToCOB
- Implement Context Renderer
- Impelement Geometry Editor
-
/*pimpage accepted*/
post new build now.
no editing yet? :(
-
Curious, what are the limits for PCS2 going to be meshwise as in Poly Count, Rexture Map number, Turrets, and subobjects?
-
the internal format doesn't have limits.. and the new BSP gen code precalcuates the size of the BSP instead of dynamically allocating a fixed 4meg scratch pad.. so theorectically... there are no limits
-
I thought you said that it was impossable to precalculate?
-
with the old code which a spruced-up copypaste of the cob2fs2 code
i completely rewrote my BSP compiler from scratch
the only real difference that i've noticed is that the new code generates a greater number of SORTNORM chunks, but i think that is related to me not having a 2s-only shortcut in the compilation [i have that commented out right now as it was causing problems]
-
Great!
I got a model here, that really refuses to convert. I hope PCS 2 willbe able to convert it. ;)
-
what error does PCS 1.x give?
-
probly the recursion error thingy.
like I was saying,
new build now!
-
well the way PCS 2.x's compiler handles the infinite recursion bug is by truncating the bad geometry
ok.. buildination - all it really can do right now is rebuild the models.. but i suppose that will allow you to test them.
-
Originally posted by Kazan
what error does PCS 1.x give?
None. The window turned white and it just disapeared after five hours. (I thought, maybe it just needs some more time... ;) )
Version 1.3.42
-
sounds like somehow it got stuck in an infinite loop.. weird. test it out once i have COB support written
[edit]
here bob was all clammering for a new build.. i give him one and he falls silent
typical :P
-
I'm really not sure about this, cause the pof also made FS2_open crash, but at least it works correct in Lith.
It looks a bit weird in PCS2...
(http://img229.imageshack.us/img229/8289/lsbug2oi.jpg)
Model download:
http://www.game-warden.com/starfox/Non_SF_related_stuff/ls_pof.rar
(maybe you're interested in this)
-
what is that model brain? terrain? it's probably a texturing problem... checking
looks like it's a lighting issue.. it's causing crashing in my openGL libs on my laptop though
-
Yeah, it's a terrain model. A test for SoL.
I don't think it's a texturing problem. I didn't even use the texture when I loaded it with PCS2, but it did load without a problem and damn fast too.
BTW PCS crashs for me when I resize the window with a model already loaded.
-
Originally posted by DaBrain
Yeah, it's a terrain model. A test for SoL.
I don't think it's a texturing problem. I didn't even use the texture when I loaded it with PCS2, but it did load without a problem and damn fast too.
i think it's a lighting issue and PCS isn't loading it's textures [if they're DDS you can forget about it - the DDS loader in DevIL is broken]
Originally posted by DaBrain
BTW PCS crashs for me when I resize the window with a model already loaded.
i haven't been able to replicate this bug.. it's related to the fact that i have to unload the textures and reload them on resize
-
Good news! Those models that caused crash before DON"T! However very few don't appear at all (no solid all black) BUT this does not cause crash and I can simply open a new model... Might be a conversion error. This was noticed earlier but I didn;t say anything as it was rare and thought it might be related and thus fixed next version
I tested quite a few I could not open before - excellent improvement!!!
-
I'm at school. well work, going to work in like a minute
-
ah.. i'm changing the way the window resizes so that it doesn't have to reload the wxGLCanvas - so that will make resizing faster, smoother and less prone to crashes..
i'm still trying to figure out why i'm getting crashes inside the ATI OpenGL driver on my laptop when the application is closing.
-
:yes2: :jaw: :yes:
*bounces back in awe*
Now that I call progress!!
Oh, and on my prior post:
Originally posted by Kazan
i was going to put buttons in there.. but it looked kinda ugly.. i'll try doing a toolbar again and see how that looks
I don't mind if it's toolbar/file menu/button or whatever. I just stated that I'd like to have the functionality to rotate the model a fixed number of degrees.
Though the pic looks like you already implemented buttons. :)
-
People who have been crashing on resize try this build out
some versions of the various openGL drivers out there don't gracefully handle glDeleteTextures(GLint count, GLint *textures) on textures with invalid TexIDs (even glBindTexture does).
that solves the crashing-on-exit and crashing-on-resize.
Also on resize it no longer destroys and recreates the controls, it merely resizes them - this means no disk access/no texture reloads on resize so it resizes smoothly.
Only problem with that is sometimes the openGL window doesn't fully rerender, just rotate the model a tick or something to make it render again.
-
I'm impressed by your woking speed. :yes:
I can resize the window without a problem now. :yes: :yes: :yes:
-
an hour lunch can net a lot of improvement :D
do you by chance have an ATI card with a less-than-recent driver? :P
-
No, NV40 6800LE, Forceware 76.45...
:nervous:
-
then both ATI and nVidia's drivers are being slutty about freeing invalid texture handles
-
Originally posted by Getter Robo G
Good news! Those models that caused crash before DON"T! However very few don't appear at all (no solid all black) BUT this does not cause crash and I can simply open a new model... Might be a conversion error. This was noticed earlier but I didn;t say anything as it was rare and thought it might be related and thus fixed next version
I tested quite a few I could not open before - excellent improvement!!!
were the "invisible ships" using DDS textures?
[edit]
went through all the trouble of compiling the DevIL CVS.. and it didn't make dds work
-
it looks sort of like the normals aren't normal, see if setting the normalize normals thingy fixes this (one line fix that you will know for sure they are normalized when drawen.)
-
I changed how lighting works and that nastiness went away bob
oh.. completion dialogs for file writing are in, i've fixed the shortcut for when a sortnorm only contains two polys - it works now and is therefore enabled: that should speed up BSP generation,
I've made it so you can switch between Textured, Solid and Wireframe views
-
I gotta question for everyone
Would you like the editors to be dialogs or integrated into the windowpane like in modelview?
[later is harder to implement well... but i'm willing to do it if you want it]
[note: all my context menus are structured around using dialogs]
-
that's what I'd prefer, though I think along the bottom would look better than the side.
-
bottom would be much harer to make look good
oh.. another build - with the features i mentioned above - plus loading menus implemented
[edit]
oh great.. there is a race condition on the release build that is causing the main loop never to come out of looping on the progress bar.. BLEH
-
ok here we go
-
wow that thing is just so much better than PCS1 so far it's amaizeing, well asside from the editing capabilities...
-
Agreed. :)
Does it already load *.cobs?
When I try to load a *cob, it doesn't complain "not implemented yet", but it starts loading... well it chrashes after a second, but this means you've probably started working on the cob import code, right? ;7
-
Tried it out, so far it seems bugless and works. The only thing that every model I load apparently uses textures from a lower LOD on LOD0. And it's a bit wierd to have the perspective be dependent on the render window ratio.(http://web396.xps1.microserver.de/wcsaga/Lynx/arrowstretch.jpg)
AS WC fan you might know that an Arrow normally is about half the lenght of what seen here. :p
-
I noticed that too, you need to change the aspect ratio every time the windo resizes.
-
Kinda works fine for me. When I resize the window vertically, model is scaled down (X and Y).
-
Originally posted by DaBrain
Agreed. :)
Does it already load *.cobs?
When I try to load a *cob, it doesn't complain "not implemented yet", but it starts loading... well it chrashes after a second, but this means you've probably started working on the cob import code, right? ;7
no it doesn't.. it means the worker thread spawned the load the file cannot created the dialog .. damn. I guess i'l have to set an errorcode and terminate the runner instead of use the runner for the popup
as for the aspect ratio bug - i'll go look at my gluPerspective call that i make OnSize()
Originally posted by Bobboau
wow that thing is just so much better than PCS1 so far it's amaizeing, well asside from the editing capabilities...
wxWidgets does all the hard low level GUI stuff for me so i can torture myself writing call backs and actually handling the input events :D
-
looks like i'm going to have to Mask those XPMs too
[edit]
i think i'm going to make it cache BSP data as well, so if you don't change the BSP it doesn't regenerate it
-
i don't know what i did, or how i did it - but the devil library i custom compiled is now loading DDS :D
-
yays!
-
ok, wtf.. it works on my laptop now but not my desktop... hrm
[edit]
oh.. it was a two-part bug.. something is wrong with my VP reader AND dds support was broke
-
ok - new build
* I got DDS to work (custom compiled DevIL)
* fixed a bug in my VP Reader
* implemented wildcard searches in my directory list and VP listing classes which significantly speed up finding textures
* Implemented BSP-caching if it detects that the model was compiled with BSPGEN or PCS Compiler v1.3.4 - will only regenerate if you change the actual mesh in these cases, otherwise just stores a copy for future use if you write a back to POF (makes pof writing near basically instantaneous)
* other changes i cannot remember
-
Does this allow you to save POFs in VP files?
-
While that would be nice, it seems like it would be more trouble to impliment that it's worth in the case that a filesize changes. The entire archive would have to be recompiled so that the files have the correct offset, wouldn't it?
-
absolutely correct stratcomm
-
Originally posted by StratComm
While that would be nice, it seems like it would be more trouble to impliment that it's worth in the case that a filesize changes. The entire archive would have to be recompiled so that the files have the correct offset, wouldn't it?
For minor changes, no. Saving the file to a temporary location and ensuring the filesize is the same as the version in the VP file would work.
-
Boink.
http://www.hard-light.net/forums/index.php/topic,34109.0.html
-
Latest version loads everything for me now.
Awesome Kazan. Awesome.
-
Originally posted by WMCoolmon
For minor changes, no. Saving the file to a temporary location and ensuring the filesize is the same as the version in the VP file would work.
which is almost certainly not going to be the same.
writing a VP cleanly from scratch is a big enough pita
-
I've blocked off screen space for the editing controls
(http://www.ferrium.org/media/pcs2-alpha2.jpg)
Current Todo List:
- Implement standard editor windows
- Implement PMF::LoadFromCOB
- Implement PMF::SaveToCOB
- Implement Context Renderer
- Cross-platform compatability cleanup
- Implement PMF::LoadFrom3DS
- Implement PMF::LoadFromLWO
- Implement Geometry Editor
-
before you get the geometry editor, maybe you should make a UV editor.
-
that will be part of the geometry editor
-
you know, maybe it would be more effective/easier to make it so that the tree extended down all the way to the lowest data, so all you'd have to do would be implement a string editor, a vector editor, and a float and int editor.
or is this the current plan, IIRC you are planning on reduceing displayed data, but I don't think you are to the degree I'm thinking here.
-
i'm reducing the number of context menus - the tree ctrl is to give you a feel for the overall model structure and to allow you to quickly add/delete items.
the Edit contexts may go back in once i have the editors up depending on how easy/hard it will for me to jump to the editor
-
ph34r
(http://www.ferrium.org/media/pcs-alpha-20050902.jpg)
-
:shaking:
-
????
-
He's aph34red of it.
-
oh yeah i titled that post "ph34r" i forgot :D lol
-
That's gonna be kind of hard to fully edit in 1024x768.
-
the panel scrolls
-
great work Kazan, as soon as i finish unpacking from the move i will be loking into this. Looks great so far though.
-
here play with this
The basic controls (non-listbox related ones) in the header editor work.
all the other editors are just stubs right now
-
wait a sec, what's with the chunck buttons on the top, I thought the editors were suposed to be accessed by the tree...
-
No one should use it often, but you still should probably put in an interface into the MOI.
-
Bobboau: when I decided to listen to everyone's desire to have integrated editors it made the context menus less-than-optimal for accessing the editors.
The tree will be used to control the context renderer (ie render gun points, etc)
-
put the editors on the other side, make the window of an adjustable size, it'll be fine
-
i tried putting it on the other side.. didn't like the appearance
allowing resizing the edges off those [relative to each other] windows = RPITA
-----
Once I get everything working I can put in a "layout preference" that will have it setup to haave this default view, this without the tree, the and the GL canvas sammiched between the tree and the editor.
how about that?
-
if I will be able to use the tree to select stuff, fine.
-
to select stuff automatically up in the editor?
-
yeah, if I select one of the thruster arrays in 'Engines' the editor window will display the properties of that array, if I select one of the points in the array the editor will have the radius, position, and normal of that point
you don't remember the big huge argument we (you me and everyone else) had and what we finaly agreed upon on what would be best? it's were the whole tree controle thing came from. the tree selects what your editing and a second editor window has all the editors, the editors are minimalist to what you have selected makeing the best use of limited space.
-
eh no i don't remember that.. but showing _only_ the pertinant sections of the editor window will be insane - i can show the appropriate editor window with the appropriate data already selected
-
I'm not sure why that would be insain, but I guess what you say would be good enough
-
After using several times PCS 1.3 this last 4 days, I think you have to represent the engine location when we put coordinates.
And other trouble in it, when I put turrets/guns or missiles the red/yellow/green line is mix with the background color (black).
I can't see where I put my turret/gun/missile into the model :/
About this PCS 2.0, I try it, but, i'm wondering, if it's normal I can't see any texture ?
-
metal have you setup your texture paths
-
Yep, I give it the same path as the previous PCS (1.3) I use actually and it doesn't work :/
I use generally the default path "c:\games\Freespace2" I try to add this path "...\data\maps" but, doesn't work neither.
-
if you give it "c:\games\freespace2" [default] it searches
"c:\games\freespace2\*.vp" vps for textures and
"c:\games\freespace2\data\maps\*" for textures
what format are your textures in.. and which build are you using? the last one?
-
I used the last one, and the textures are in .pcx only and dds for some.
-
you need to set your path to "c:\games\freespace2"
NOT c:\games\freespace2\data\maps\
it automatically appends the \data\maps\
-
it looks in 'c:\games\freespace2' first though, right?
-
It didn't work :/
-
no it doesn't bobboau - i thinks in VPs in c:\games\freespace2
i'm going to modify the code later to check the roots too
right now it only looks at
[path]\*.vp vps
[paths]\data\maps\* raw files
metaldestroyer: then i don't know, you've set something wrong, or your ship has all DDS textures and DevIL's ability to read .DDS is flakey
-
sence you can put in multable texture paths, why not just have each path check [path]\* and [path]\*.vp, and by default set it up to c:\games\freespace2
and
c:\games\freespace2\data\maps
and it would probly be a good idea to have it check the folder were the model was loaded from first, or makeing an opption for it.
-
i was going to make it check
[path]\*
[path]\data\maps\*
[path]\*.vp
-
Hey KAz, I thought o a neat feature that might be very usefull - SCALING!
You have a scale bottun and you just imput the modifier by which to scale the model. Of you want a model 75% the size of the original one you imput0.75. If you want a 50% larger one you imput 1.5.
What PCS should do is scale hte pof itself and them go trough the engine glows coordinates (and radius), docking points, subsystems coordinates(and radius), turret fire points, path coordiantes (but shouldn't touch the radius there), and eventually glows and insignias and multiply each value by the modifier and save it..
Do you think it's doable?
-
How about rotating? (See MetalDestroyer's thread)
Edit: Just thought of what might be a nice feature, some X/Y/Z arrows that could be toggled on/off so you could make sure that the model is aligned properly.
-
Another stupid question, do you intend to make a new built for the cob 2pof conversion into PCS 2.0 ?
Because, I don't know why I got a Stack Overflow. The model have only 2k polycount, no more.
(http://img396.imageshack.us/img396/6465/pcsstackoverflow3ls.jpg)
-
See tip 2 in zee Wiki! ;) (http://dynamic.gamespy.com/~freespace/fsdoc/index.php?pagename=PCS)
-
Thx.
Another bug in sight with the old one (1.3), when trying converting a model (cob2pof), the PCS process wasn't responding and crashed.
-
1.3.4 is the latest version and slowness then crashing typically happens on HTL models.
PCS 2.x has a completely rewritten BSP compiler that is entirely my code - no more throwbacks to Gnudson's cob2fs2
-
so will youput scaling in or not?
-
maybe
-
(http://www.ferrium.org/media/pcs2_linux.png)
-
what? I don't see anyth.. what th'hell be that black thin' that looks like it's filled with co... be that a skin ... wait a second... that ain't XP! that ain't XP at all! you've got in linux don't you! yay crossplatform APIs!
-
Are there going to be MoI calculator in the PCS? Or is it there already?
Or are there even any real Moment of Inertia calculator somewhere?
-
Another suggestion, could you include an option to change the background color (Black, White, ... ) because in the PCS 1.3 or 1.4, When I got a dark texture, it's very hard to notice guns/missiles and turrets. The yellow/green/red line is too dark, and so, I can't see with precision where I put my guns/missiles/turrets.
Another thing, could you put lines like turret for Engines glow ? because it's hard to put them more precisely without going into guns/missiles onglet.
-
"Fuel" ??
-
FUEL is the chunk name for engine glows
-
Any news about it ?
-
nope.. i work on it when i feel like it which is not very often with my day job being software developement.
mostly i play everquest - right now i'm applying for membership in one of the top raiding guilds on my server and am about to assemble a big EQ website.
-
somone once bought me a copy of eq2, i took it back to the store.
-
eq2 sucks monkey **** - SOE has expressed regret at naming it that
-
howd you get the moneky?
-
look in grognards
-
PCS2 would be nice, kind of annoying how PCS crashes after opening one or two models...I tried compiling it myself, but got more missing lib errors than I felt like dealing with at teh time.
-
Agree, PCS crash with models which have more than 8K poly. :/
And ModelView doesn't work too with the Highlimit patch.
-
You should complain to Kazan about it. Kazan will then ignore you. If you're lucky :P
-
umm.. it shouldn't be crashing with large models....
-
compiled the ragnarok fine, at 16k polies.
-
Just did a test, and PCS Facet will crash with more than approximately 15000 polys in lod0 for me. (PCS 1.3.4 just crashes on any attempted conversion - is it even the latest version? :\ )
Also, while I'm here and because it's been bugging me no end, it seems that PCS doesn't like something about my new setup - AMD 3800+, 2 Gigs RAM, R 9800 Pro 128. What happens is that whenever any version of PCS with the viewer is open, it uses 99-100% CPU power. Turning the viewer off it returns to normal.
It's done it on 2 out of 3 AMDs I've checked it on, but none of the 3 Intel ones, so I'm lost as to what could be causing it (never did it on my old Intel setup).
Fortunately, PCS 2, even in the alpha stage opened a 32 000 poly model I have and ran it blazingly fast, so the future is bright. :D
-
Soooo, where can I get PCS 2.0? I can't find a link in the thread or on Sourceforge.
-
the viewer in PCS 1.x was an hack and it runs a loop drawing over and over as fast as it can even when it doesn't need to - hence the cpu usage - it also has some static limits in it and I didn't understand the BSP completely...
PCS 2.x is basically a rewrite from scratch - i can precalculate the size of a BSP i am writing, it only redraws when it detects it needs to [which it doesn't always catch :/], it has it's own internal file format so writing loaders isn't as difficult.
[gal]
i believe i've posted it as an attachment somewhere in here
-
i believe i've posted it as an attachment somewhere in here
I couldn't find it... And yes I know I haven't been following this as closely as I possibly should have (all my latest attempts to convert cobs -> pofs using old PCS have failed, even those that converted fine before now :wtf:) IIRC I keep getting that recursive thingy... [Raptor knows nothing about code]
Would you mind post a direct link? Please? :nod:
-
Attachment's are gone - probably in the whole forum transfer stage. See? (http://www.hard-light.net/forums/index.php/topic,34673.msg721894.html#msg721894)
it runs a loop drawing over and over as fast as it can even when it doesn't need to
Hmm, any reason that may only occur on some systems and not others?
-
You wouldn't see it as much on a multiprocessor, but an infinite loop is an infinite loop. Which is why I close the render winidow the second PCS loads.
-
How to avoid the polygon overflow in PCS 1.x ? The model has only 1k polygons, not more. :confused:
-
Don't use PCS 1.x. It's obsolete.
-
So, which Cob 2 POF should I use for High Poly ?
-
Don't use PCS 1.x. It's obsolete.
Wait... PCS 2 can't convert models yet. So which PCS should I use?
I got a rather complex model for conversion.
-
Not sure, I think you'll have to stick with 1.x for now, at least until 2 can convert.
I will be absolutely bloody marvelous if this does end up supporting LWO format, my single biggest block between me and getting models into Freespace is having to convert LWO to COB, which you have to go via .OBJ to do, and even then, it's not always 100% happy with Lightwave's UV mapping :(
-
Err. I skimmed through it too quickly when I wrote this and just assumed that he was using a very early build of PCS. Nevermind then. >..>;;
-
things around here are rather discouraging my working on stuff.. plus i have my new everquest website project
-
I still refuse to accept everquest as a legitimate excuse for not doing something. Ever. :p
Seriously though, I would love a good, stable, designed-with-no-limits POF editor as soon as possible. I'd love to be able to tell people "this is how you fix..." instead of having to preface it with "If you know Hex, this is how you fix [...], or just send me the model" every time I get asked a question.
-
I'll work on it when I feel like it.. right now i'm in the process of applying to a high end guild to boot
-
the only gripes i have about the current pcs is the glopoint importer doesnt work, and id like more autogen features. my experience is if your pof doesnt convert, theres something wrong with your model.
-
Funily enough, last night I tried to convert something again, and it worked (took almost a half minute to do it, but it worked) :wtf:
Maybe it was because the ship was at half scale... :confused:
-
the bsp calculator doesnt like polies that are too small. you know the kind that you cant see, sort of what you get when you do a bolean and forget to tie up all the loose ends. also i find that the chamfer tool in ts6 does it at times if you try to camfer something complicated. simply look over anything you did something stupid with, and find those pesky micropolies. by changing the scale you simply make the polie big enough not to crash pcs, none the less its bad practice to use a model with a known and uncorrected flaw like that. i think max's optimise can correct this pretty much instantly.
-
I want to know something :) When are you going to release this POF Constructor Suite 2.0 ?? :)
Thank you for your answer :)
-
when it's done
-
:lol:
As long as we don't need something like Steam to use it :p
-
no you need my new patented "Warm Moist Air" system :D
-
no you need my new patented "Warm Moist Air" system :D
Do that and I'll mail Cobra, Ephili, and Liberator to your house. :p
-
I think that is equal of putting the "fear of god" into someone.
-
ROFL
'Please Enter your Cond-N-Sation™ Keycode'.
-
lol
-
:rolleyes:
LoL.