Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on May 09, 2007, 04:17:43 pm
-
http://ferrium.org/media/pcs2-alpha-20070507b.zip
try loading .cob's
-
Yihaaa !! Kazan is back !! I hope I could at least convert some Star Wars models without having those error message :p
-
http://ferrium.org/media/pcs2-alpha-20070507b.zip
try loading .cob's
Wow, i have been waiting for this for so long it brings tears to my eyes.
I love you...
-
well ive hit this version with several different heirarchy setups and couldnt make it apear to screw up. it would be nice if we had some sobj data which i could view so could make sure that everything is in order data-wise.
-
Doesn't seem to do anything useful with cob for me. (visually)
On the left the numbers look like they are right. The model view screen remains black.
It opens pof ok, but without texture.
Program was run from dir containing dll's. - cobs were in fs\data\models - cobs generated by pcs1
Another cob (known to have problems) does show model image - but viewport seems to be inside ship.
-
you cannot directly load COBs generated by PCS1.x
you also have to setup your texture paths
-
you cannot directly load COBs generated by PCS1.x
you also have to setup your texture paths
Thanks
Didn't notice the default path had \games\ in it
-
Getting some strange smoothing errors with this one that weren't present in the previous:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/PCS2-Loki-SmoothingBug.jpg)
Also, about textures - setting a texture path as say, C:\Freespace2\ will enable it to use any textures in VPs in that folder, but it doesn't propagate down to the data\maps folders. Should it? Or do we need to add C:\Freespace2\data\maps\ to the texture paths?
And finally, I'm not sure if this will be of any help to you, but I'll post it anyway - I'm occasionally getting a crash on exit:
"ModName: nvoglnt.dll" and it spits out a
The instruction at "0x69679004" referenced memory at "0x00000099". The memory could not be "written"
type error at the same time.
-
C:\Freespace2\
will search for textures in
C:\Freespace2\ (files)
C:\Freespace2\data\maps (files)
C:\Freespace2\ (vps)
and i don't know your model well enough to see the errors myself
-
Hmm - it doesn't seem to though. Just tested again to be sure, but it seems if I have a dds map in data\maps and set the texture path to the parent \freespace2 directory, it won't load and just displays white.
Changing the entry to include the data\maps\ loads it fine.
-
that's prob a bug with the new search code
-
Ok. :)
And the smoothing errors are the splattering seen all over the hull in weird places. This is what we get with the exact same scn file, but with the previous version - the one that took much longer to convert:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/PCS2-Loki-NoSmoothingBug.jpg)
-
Yep, only textures from the VP are found, those in /data/maps/ are ignored.
Also, it seems to randomly choose which LOD gets displayed, and I cannot change it. And lastly, an option to pan the model around in the render window is necessary.
Overall, I'd say this is on the right track :yes:
[attachment deleted by admin]
-
YIhaaa :) PCS is back :)
Let's download and try alpha version of PCS 2 :)
-
Ok. :)
And the smoothing errors are the splattering seen all over the hull in weird places. This is what we get with the exact same scn file, but with the previous version - the one that took much longer to convert:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/PCS2-Loki-NoSmoothingBug.jpg)
now that i think about it im seeing this too. the b version is faster but it lacks the really good smoothing of the previous version. remember how good the smooting on the chimera looked back when it had its sobjs splayed out all over the place. now same model looks as garbeled as the first loki va posted. i personally dont mind waiting longer if the results will be better. maybe a fast smoothing option in the settings, which can be disabled for final versions, and enabled for test compiles. then again the compile time isnt _that_ long.
-
by "previous version" to you mean the non-B revision from that date of PCS2 builds, or do you mean PCS1?
if the first then that means my optimization introduced a bug that i need to correct, if the second.... i dunno, bob wrote smoothing for PCS1
-
Awesome, finally got PCS2 to load on my PC.
PCS2 seems to load ships upside down or the viewpoint directly under them. And when I loaded the Hercules it looked a little... longer, if you will. Not the "fat" kind of Hercules we all know and love, but a slightly stretched out Hercules.
I forgot this was test build when I started looking for the eyepoint editors, weapons, paths, docking points, whatever. :D
-
by "previous version" to you mean the non-B revision from that date of PCS2 builds, or do you mean PCS1?
if the first then that means my optimization introduced a bug that i need to correct, if the second.... i dunno, bob wrote smoothing for PCS1
i mean the non-b version of pcs2, just to clairify.
-
Yeah - non-b version of PCS2 here too.
-
ok, my optimization introduced a bug then
-
today i'm relaxing.. tommorow i may work on PCS2 some... then probably on FeRez some
-
here is a test build with bobboau's latest GUI, some fixes from me - including hopefully having fixed the smoothing calculator so please check it
http://ferrium.org/media/pcs2-alpha-20070606.zip
debug executable (pcs2d.exe) and release executable (pcs2.exe) included so it's larger than normal
oh.. and screenshots
(http://ferrium.org/media/pcs-alpha-20070606a.jpg)
(http://ferrium.org/media/pcs-alpha-20070606b.jpg)
(http://ferrium.org/media/pcs-alpha-20070606c.jpg)
-
Odd question, what formats are textures suppose to be in? and are they viewable within a vp file?
I can load up saga's model with textures, but mine are all blank.
I've got it setup as:
d:\Program Files\Wing Commander Saga Prologue
d:\Program Files\Wing Commander Saga Prologue\Scooby
preference texture path as : d:\Program Files\Wing Commander Saga Prologue
-
Looking really nice :) Really am going to have to start restoring files to the new computer, unfortunately, the ability to have an enormous fleet in X3 without any slowdown has kind of dragged me away from FS2 for a while :nervous:
-
d:\Program Files\Wing Commander Saga Prologue
d:\Program Files\Wing Commander Saga Prologue\Scooby
having those as your search paths will result in:
Search: d:\Program Files\Wing Commander Saga Prologue\data\maps<files>
Search: d:\Program Files\Wing Commander Saga Prologue\<files>
Search: d:\Program Files\Wing Commander Saga Prologue\<vps>
Search: d:\Program Files\Wing Commander Saga Prologue\Scooby\data\maps<files>
Search: d:\Program Files\Wing Commander Saga Prologue\Scooby\<files>
Search: d:\Program Files\Wing Commander Saga Prologue\Scooby\<vps>
supported extensions (in their search order)
char *extensions[] = { ".pcx", ".dds", ".jpg", ".png", ".tga", ".gif", ".bmp" };
-
edit: Nevermind.... Found the cause. I extracted the textures from the VP for the Saga Prologue stuff, but not mine
Strange. When I had my textures located in d:\Program Files\Wing Commander Saga Prologue\Scooby\data\maps they wouldn't load but in d:\Program Files\Wing Commander Saga Prologue\data\maps they would
-
Great work Kazan...
My observations. I had a incident I couldn't repeat. I had zoomed in and moved a modela bit and then moved teh left side tree inteface and probably bumped something and the model was still loaded but visually disappeared. there is no refresh image button so I tried goign from textured to wire to solid blicks and nothing showed it again.
Shuttign down PCS and reloading was only option. No idea what I did.
For construction purposes if you keep pcs open can you have it remember when you chose the option to show all file types to open. when workign wiuth multipel files you need to rechoose that each time (would make things more efficient).
Also can you impliment a MV type texture finding as a native default feature. So if you got ships all over the place (like wips) and a separate modding section, you don' need 1000 preset paths and as long as your textures are in the same folder as the file you want to view, it will locate them?
:yes:
-
"as long as your textures are in the same folder as the file you want to view, it will locate them"
I like that idea
-
i could probably add that
just remember each search path i add to the system slows texture loading down
-
Does it once it finds a texture always use that path with other textures?
The ship textures is located in d:\Program Files\Wing Commander Saga Prologue
The turret textures are located d:\Program Files\Wing Commander Saga Prologue\Scooby\data\maps
(http://img.photobucket.com/albums/v356/Shodan_AI/textureproblems.jpg)
If i move the ship textures back to Scooby\data\maps then nothing will load.
-
move everything into scoobie.. then add a third path that's just dead.. like d:\games\freespace2 or something and tell me if that fixes it
-
Yup that works :)
Let me guess, off by one error?
-
yup, caused by floating point to integer conversion... i think i have it fixed in code so next build remove the dummy entry
-
i cant seem to get any materials to convert from scn files.
also that bug where pcs would lock up when trying to load a missing texture is back.
-
you cannot get materials to convert from scn files? that statement does not compute
and what bug about locking up..... i've never had it lock up oni my trying to load a texture...
what format are your textures in?
-
I'll just move future stuff to a preset path like -model wip each time I work on something then.
last thing you want is to add wip files to your mod just for pcs2 and then if it doesn't work for some reason have to fish everything out manually when you might have to do that later (anyway) cause of FRED or in-game problems (yet another hassel in the construction phase). ;)
I forgot what else I was going to say, but on a whim I loaded up a fighter I will never use and it handled the 50k model no prob. :yes: I fully expected it to crash but it merely lingered 4-5 full mins and then bam there it was. Nice...
-
the smoothing calculator is soo ****ing slow.... without it that model probably would have loaded in seconds.. if i can get bob to take a look at my smoothing calculator and see if he can think of anything to make it more efficient
-
Any hope of getting MoI calculator (or even rough estimator) with the PCS2?
Also in left hand tree view... Specal -> Special (?) and Auto-centering -> Auto-Centering (?)
-
you cannot get materials to convert from scn files? that statement does not compute
and what bug about locking up..... i've never had it lock up oni my trying to load a texture...
what format are your textures in?
grrr, i dont have time for detailed bug reports.
i have a scn file, in that scn file there are materials that contain the textures and smoothing data. if i convert a scn such as the dante the texture list shows nothing and the model apears untextured.
the second bug is more a re-occurance of an old bug where if there was a missing texture and a lot of texture dirs, the program would hang. the texture wasnt missing but it was just an ani which isnt supported. all my other textures were dds. do i ever use anything other than dxt1 or dxt5?
grrr, gotta go to work. :mad:
-
devIL supports dds, we should too.
as for the auto-facet code, it should look something like this
for(each polygon (A) ){
for(each vertex (V) in the polygon){
V.norm = A.norm
for(every other poly(B) the vertex (position component) is used in){
if( dot(A.norm,B.norm) < A.facet_angle )
V.norm += B.norm
}
normalize(V.norm)
}
}
there realy arent a lot of short cuts you can make, you can not for example, set the normal of two polygon verts at the same time if they are within each other's angle, because there may be another norm that is one normal's angle that is not in the other.
as long as load times for models are less than 30 seconds I don't think anyone is going to complain.
alternatively, you could attempt to figure out a way of supporting smooth groups, however this would likely require writing a custom shader for TS.
-
that's pretty much what i have it doing... plus some result caching for speed of execution... problem is it takes a wile... maybe up to a minute per 10k polys from the numbers he got on that 50k poly model... though i'd be interested in knowing his cpu
-
trusepace seems different tham most other modeling programs. rather than having actual vertex normals, it just uses its material system to determine how to extrapolate the vertex normals. not sure if they actually get stored in the model or not. at least thats the way it appears on the outside.
the way i was dealing with materials towards the end of my truespacing. was to assign a bunch of flat shaded materials to different sections of the ship. theese were easy to select for uv projections and could each have a different smoothing setting. later i would assign textures to them. for ships like the ragnatok, which only used one texture, one had to avoid the urge to apply a new material with that texture to the whole model thus destroying any potential for a good smoothing setup. i had to create a new material with the texture and paint over the old one.
this worked well from a modeling perspective. but pcs seemed to place no hard lines between the different levels of smoothing the way that max does. i think it would look better if it did.
-
truespace supporst three smoothing modes - faceted (no smoothing), smooth (average normals of all polygons sharing the point) and angle-based smoothing - IE if average normal of owning polygon with all other point-sharing polygons who's normal angle is < X degrees
PCS2 supports all these modes
-
Hey awesome; this build not only fixes the smoothing error brought up earlier, but it also seems to improve the overall smoothing of the ship:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/SmothingComparison.jpg)
A little hard to see, but there's a hard line through the flat surface in the PCS 1 pic that isn't present in the PCS 2 version - they both came from the same scn file.
It's not just there either, all over the hulls of the ships I've test converted through this latest build have similar small but still noticable improvments to smoothing. I'll have to run the lucifer through this when it's fully operational, since it has countless smoothing problems.
Nice work. :D :yes:
Also, is saving as pof supposed to be tested at this stage as well? If so, I have a rather...interesting...bug to report. ;)
-
the bug i introduced with smoothing in PCS2 that i just fixed was a total faceplant... when I wrote my optimizations to the code to speed it up i used some memory management optimizations - used a larger buffer than I needed and as i needed to enlarge the buffer i'd double it's size.... this requires that once you're done loading information into it you have to reduce it's size to the correct size.... i forgot to do that last step.. so the bug was averaging in [buffer size]-[real size] (0.0, 0.0, 0.0) vectors
-
is it at all possible to put hard lines between (truespace) materials?
-
it not longer has a mapping to the COB/SCN's materials when it's doing smoothing calculation
-
New build for today... report all bugs in the new PCS2 mantis linked in my signature (only bugs eixstant in this version - if the bug existed in a previous build pls verify that it is persisting in this build)
http://ferrium.org/media/pcs2-alpha-20070613.zip
-
Had a short time before work tonight to try this out. Tried pof & cob from my shipyard folders as with previous builds. I can't see my models in solid or wireframe mode anymore. Didn't try texture mode cause they are not in the directory anyway. :D l8tr!
-
that is one of the bugs we have yet to solve, try streaching the render window so it is wider than it is tall, this should resolve the issue temporarily.
-
Yup, that did the trick! Thanks.
I guess last time I opened the window first and made it bigger then tried diff models. No big deal, I was worried for a sec though. ;)
-
please write up a report for that bug in the PCS2 mantis (link in sig)
-
http://ferrium.org/mantis/view.php?id=1
I could stand haveing my account upgraded there BTW.
-
upgrading your account
-
ok, new build from me (http://freespace.volitionwatch.com/blackwater/pcs2.zip)
this one has a number of small fixes, mostly having to do with data transferring between the different subsystems to keep stuff updated in a more natural way. fixed the bug with editing one type of weapon point eraseing the other type, added in a weapon point convergence calculator, haven't been able to test it all too much because we currently lack 3D display capabilities for chunck data.
added a PINF editor, you can use this to make comments for your model.
I added some skeliton code for chunk import/export, I'm probably going to need to do some seriuos low level reorganization to do that in an effechent manner, so for the moment those buttons are useless.
tinkered with the scroll zoom to try and make it a little faster, and proportional to how zoomed you were (zooms faster the farther away you are)
[edit]oh, hot damn, I fixed that render bug, reuploading, yay! our first mantis bug fixed![/edit]
hey Kaz is there any way you could give me a function (or four) in the GL canvas that will produce the forward, up, and right vectors and position of the camera in model space?
-
I think I may have identified an infinite loop in TextureControl::LoadTextures you have a do/while loop and the sentinel values never seem to change, filenum keeps getting set to the same thing, and img_type stays at IL_TYPE_UNKNOWN cause it can't find the file.
everyone else I just uploaded yet another new build, this one I made some changes to the options dialog, tell me if you like the way it works now.
-
hey Kaz is there any way you could give me a function (or four) in the GL canvas that will produce the forward, up, and right vectors and position of the camera in model space?
i don't know how to do that and i've never been able to find the math :( find me the math and i'll write the functions
[edit]
oh.... the camera isn't what moves btw.. the model is
[/edit]
I think I may have identified an infinite loop in TextureControl::LoadTextures you have a do/while loop and the sentinel values never seem to change, filenum keeps getting set to the same thing, and img_type stays at IL_TYPE_UNKNOWN cause it can't find the file.
it's never gone Inf Loop before - i assume you're talking about text_ctrl.cpp (1.19) (http://alliance.cvs.sourceforge.net/alliance/pcs2/tex_ctrl.cpp?revision=1.19&view=markup) 183 to 203
i think i see it now too... if it doesn't find the file it goes inf loop... which is odd that it's managing not to lock the application because i have ships that's textures won't come up... probably have unsupported img types so there is a match
[edit]
i'm a dumbass... no inf loop there
FileList.cpp (1.10) (http://alliance.cvs.sourceforge.net/alliance/pcs2/FileList.cpp?revision=1.10&view=markup) lines 262 to 273
wild_search(...) returns -1 on failure to find file/hitting end of list - which causes (img_type == IL_TYPE_UNKNOWN && filenum != -1) to fail because filenum = -1
filenum is also dual used as wild_search's resume token.
-
I know the camera doesn't move, but I need to know the camera's orientation and position in local model space.
if you can just get me the matrix(es) that is(are) set I can do the math. actualy, I probly wouldn't need to do the math if I had that, camera matrix is basically those vectors stacked on top of each other. but I'm not sure how you are doing that, if I just had all the relivent matrices I'm prety sure I could figure out what I wanted. unfortunately you seem to be storing everything as rotations, rather than matrices.
and all I know is after configuring my texture paths I got in an infinite loop there, filenum never changed, and img_type was constantly the same too.
-
openGL handles all the matrix math for you.. i have a matrix math lib which can do the calculations for you.. but i would have to copy it into PCS2 because it's not included right now
-
all I need is the matrices, and maybe a few basic matrix math things, I can make them myself without too much of a problem, all I can not do is get the raw materials (the model space and camera space matrices) from OGL, cause I don't know OGL, I tried looking up how to get, them but the functions involved didn't seem to have a matrix class or an array of floats, so I figured I'd just ask you to do it, cause it seems like it should be something trivial.
if posable I'd prefer 4X4 matrix for everything, makes the higher level math so much easier.
at this point none of the submodels have there own orientation do they?
-
nope... subobjects only have an offset from parent... if we actually wanted to animate rotation.. we would have to worry about submodels having own orientation
why are we worried about this?
PS:
http://alliance.cvs.sourceforge.net/alliance/traderoutes/code/core/matrix.h?revision=1.2&view=markup
http://alliance.cvs.sourceforge.net/alliance/traderoutes/code/core/matrix.cpp?revision=1.2&view=markup
i'll copy those over
-
ah, alright! :D
I was just wondering, if the submodels had there own orientation it would make finding the camera in local space a bit more complicated. it would be nice to have it later though, as we'd be able to import one model and copy it, and this could allow for a shared vertex/index buffer between these objects in FSO (and PCS). but that's a year or two down the road so it was just a thought I had as we were talking about all this matrix stuff.
-
i'm willing to be you could construct a single vertex buffer for an entire model and then index buffers for each submodel. i doubt openGL requires that every time you call drawing index buffered segments of a vertex buffer they have to be in he same transform
now... PCS2 doesn't need to draw via the vertex buffer (And really shouldn't for realtime updates when geometry editing)
right now PCS2 only draws when something causes the glCanvas to need to be redrawn.. or when we instruct it to (like.. every time the selection in the treeview changes.. it should be forced to render again - so that when we put the context rendering it updates)
if we want to show submodel rotation we will have to setup a timer to make it redraw 30 to 60 times a second (make it a preference slider)
i also eventually want to do shine/glow/etc and be able to have the user have a few lights he can move around, color, etc - but i don't know how to do that
(nor do i know how to draw glow points)
i really either need taylors help.. or you to tell me how to do these things and i can probably write te openGL code to do it.
-
there is a way of model instancing using some sort of vertex shader, there is also a way to draw verteicies with different matrices.
-
I found the source of the infinite loop, num_exts was 5 when it should have been 7.
so it would find the file, but wouldn't load it, and sence the fiile exsisted, but not loaded it would keep trying to load it.
could it be posable for it to look
file.ext1
(vp)file.ext1
file.ext2
(vp)file.ext2
rather than
file.ext1
file.ext2
(vp)file.ext1
(vp)file.ext2
-
also just figured out why it was crashing on a lot of POFs, (awacs2t-01.POF) num_cross_sections should not be unsigned, I remember this as a peculiarity of this if there are no cross sections num is -1 not 0.
num_lights might be the same, don't recal off hand.
-
I found the source of the infinite loop, num_exts was 5 when it should have been 7.
so it would find the file, but wouldn't load it, and sence the fiile exsisted, but not loaded it would keep trying to load it.
could it be posable for it to look
file.ext1
(vp)file.ext1
file.ext2
(vp)file.ext2
rather than
file.ext1
file.ext2
(vp)file.ext1
(vp)file.ext2
isn't the texture loading code complex and slow enough already? ... i really don't like ****ing with that code as it's a massive pain in the ass.. and what you suggest would seriously slow it down (worse case scenario is num_exts times slower
also just figured out why it was crashing on a lot of POFs, (awacs2t-01.POF) num_cross_sections should not be unsigned, I remember this as a peculiarity of this if there are no cross sections num is -1 not 0.
i already fixed this on my system
-
same place new build (http://freespace.volitionwatch.com/blackwater/pcs2.zip)
I fixed a bunch of bugs, and added some more options (light colors! oh so fancy!)
oh, and I added the ability to edit cross sections, even though I'm not completely sure what they do.
-
make you make a policy of every time you post a build you cvs commit
-
well, ok, I was trying to have people test for bugs first, but I guess they don't do that much anyway.
-
and so Bobboau said "let there be omnipoints (http://freespace.volitionwatch.com/blackwater/pcs2.zip)" and there was, and there was much downloading to be had by all.
OK, out of sheer desperation, I made a very poor omni point renderer, I realy hope kaz rewrites it, cause I don't like it, if I knew OGL better it'd been a zillion times better, but anyway. yeah, you can see what you're doing now. also if you hold down ctrl you can move things with the mouse (rclick=x/z, lclick=y. very primitive at this point). and the scroll wheel edits radius for things that have it. I plan on haveing the ability to rotate normals as well eventually.
also the fetus pink color is only temporary, I'll actually work on getting everything customizable, soonish.
if I can get my camera vectors in model space I'll be able to make things move the way you would expect them to and I'll be able to develop a hyper cool ray picker, that'll let you just click on the thing you are interested in and it'll be selected.
make sure to tell me what is wrong with it,
(http://freespace.volitionwatch.com/blackwater/mantis.jpg) (http://ferrium.org/mantis/)
I'm going to take most of tomorrow off, so you have some time.
-
Any chance we could get another test build soon? I've got a little bit of free-ish time today to do some more testing - especially checking out the bug #5 fixes. :)
-
ok I think I got all my bugs done, including the weapon point bug (BTW any time you see that error message it's a highest priority bug, that is code which should never be reached), but that one was a bit wily so make sure.
I also updated my code so if Kaz committed his changes they should be in here too.
and so far I've been just updating the same file, so if I forget to post the link it's here
http://freespace.volitionwatch.com/blackwater/pcs2.zip
-
hey, kaz, did you forget about that matrix class, I was going to just add it my self, but it looks like it's got a bunch of other dependencies.
cause I'd realy like to get to work on a ray picker, but I need both the camera's and the model's position and orientations, and preferably some matrix math stuff, and I don't want to write all new matrix stuff just to have it replaced in a few days.
-
i thought we ended up with you not needing it.. i'll import it after physics today
-
I updated my zip, I added a neat new control, a suggestion wrapper for exsistng controls, you hit a little button and it gives you a few good options for what should go into the text box, will probly be most useful in the special points and model properties fields.
-
I just corrected a serious bug (http://ferrium.org/mantis/view.php?id=6) in COB/SCN->PMF loading that resulted in all normals being inverted - this is along with other (related) bugs (http://ferrium.org/mantis/view.php?id=5)
these fixes should be present in the next build posted
-
Ok, now that is just pure awesome all in one button. :D
Can I suggest an auto-turret entry btw? So in the subobject properties suggestion, you have all those ones, plus one that will add in one click:
$special=subsystem
$fov=180
$name=Turret
Actually come to think of it, for the subobject properties window, I'd suggest having a 'default' or 'sample' entry for most (or maybe all?) possible types of subobject. That'd include one for a: detail box, turret, destroyable subsystem, rotating subsystem, simple triggered animation and for when it is reintegrated into FSO, one for off axis multipart turrets.
Any I missed, and would this be possible?
And also, I noticed these in the submodel property suggestions box, and I've never heard of them before.
$stepped
$steps=4
$t_paused=2
$t_transit=6
What chunk of functionality have I been missing out on here? Again. :(
And crikey the pair of you kill bugs fast. I'll have to find some new ones for you now. :p
-
turret's automatically have their properties filled on load from COB/SCN if you name them to the turret naming convention
(we need to write some nice FULL DOCUMENTATION for PCS2 - i plan on using wxHTML panes and write the docs in HTML)
-
http://www.ferrium.org/media/pcs2-alpha-20070618.zip
good number of bug fixes.
-
VA those are for stepped rotation, the shivan gas miner uses it, as does the Golgotha, it's a retail feature.
I'd have to do a good bit of recoding to get multable lines in the suggestions menu, but I can probably do that eventually, as it is now what is in the menu is what will be drawn, and having the full subobject properties for a turret would be too much to cleanly fit, so I'll need to recode to have separate labels and content, but first you mentioned a few things I forgot, I'll add those.
-
well... because OGL does not differentiate between model and view matrix, and only has just the one, it looks like I am going to have to keep track of them myself... which means I might as well set up a full matrix stack for the model and proper set functions for the view.
I WILL have a ray picker!
hey, how do I get access to this (http://www.opengl.org/sdk/docs/man/xhtml/glLoadTransposeMatrix.xml)?
-
A retail feature!? So that's been there the whole time, and I've never seen it. How depressing. :(
turret's automatically have their properties filled on load from COB/SCN if you name them to the turret naming convention
I mean for when you have a pof without that data already there, though thinking about it, that should be a pretty rare circumstance. :)
Anyway, I think I have a couple of new bugs to report. I'll mantis them when I know more in a few minutes.
-
arg, seriusly, how do I get glLoadTransposeMatrixf?
it says it's a 1.3 function, I can't tell what we even have, let alone how to change it.
-
if it's not coming up as a defined function it means i'll have to import my gldriver - microsoft's headers only define functions for OGL 1.1, but i can use SDL to get functers for the others
-
Ecck! Is the paths section suppose to have tons of lens flares?
(http://img.photobucket.com/albums/v356/Shodan_AI/flares.jpg)
-
i didn't write the code for that
*looks at bob curiously*
-
Just double checking...
- That the shield and insignia sections haven't been done yet right? They currently just display the header editor.
- And also that import data is similarly not-yet-done, since the load buttons don't do anything at the moment.
And Scooby - it's quite possible that those paths are all fully correct. Just look at an Orion in path view. ;)
However, it might be a good idea for modder sanity to have an option to only display the currently active path. :D
-
bob doesn't currently plan on allowing signia editing or shield editing.... though eventually selecting the shield item should cause the ships shield mesh to be rendered
-
well, I wanted the non-selected paths to be visible too, the selected path should be vastly brighter than everything else. the colors for everything will be customizable soon so you can just set the unselected color for paths to black and you won't see them anymore.
does that sound good?
and yes, insig, shield, and import/export are not implemented yet, insig will probly be a while, shields will probly do nothing but display the geometry for now.
geeze all the sudden everyone is a postaholic..
-
we're posting working builds.. and i'm sitting around waiting while raid buffs up in eq
-
Well....if you think about it, this is kinda the 'big thing' happening at the moment - the birth of the one modding tool to rule them all if you like. ;)
Anyway - yeah, the selected path and it's points are brighter than the rest as well as drawing the path line itself, so that definitely works. (though the selected point becomes a solid, non transparent circle making it a little tricky to use for the moment)
-
i don't really like those "semitranparent spheres" around it... maybe if they were much smaller and were geometry (ie lines) they would be better to show radius - ie make their actual radius the log(10) of the path point radius
-
well it was more, I've been waiting for activity all day, and then suddenly I tried to post and it was "warning someone else posted" like three times in a row.
thats all.
they can't be smaller the purpose is to show you what the radius is, if you make them smaller than what the radius is it'll be misleading the user and showing false data, I tried my best to make it look nice, but it is suposed to have a function, just cause it looks ugly doesn't mean you should change it to be something it isn't.
but the paths do need to be tweaked quite a bit.
-
PCS1 didn't show the radius and people were just fine
-
Sorry I was away....
The model was converted using PCS1. (What state is the PCS2 converter?)
I don't mind the spheres, given that they look right.
This was the paths that I imported from:
(http://img.photobucket.com/albums/v356/Shodan_AI/flares1.jpg)
-
PCS2's converter works A-OK
-
Good.. I was worried about inverted polys, etc...
-
The spheres are great, they do a better job at showing the radius than a cube.
PCS1 didn't show the radius and people were just fine
I had to use Modelview to edit anything with a radius because it didn't show up and the X mirroring for subsystems. And with that giant memory leak work never went too fast.
-
Spheres are somewhat ok... but they need lines between to make things understandable
-
well, the paths are suposed to have lines between them, but the only one wich is realy visable is the selected path.
-
Sorry I was away....
The model was converted using PCS1. (What state is the PCS2 converter?)
I don't mind the spheres, given that they look right.
This was the paths that I imported from:
http://img.photobucket.com/albums/v356/Shodan_AI/flares1.jpg
Yeah that looks about right then - you can see the selected path at the front and just a bit of the line as well. It would probably help if we had an option to turn the spheres on or off though, and even then only display them for the active path. :)
PCS2's converter works A-OK
Hmm, I'm not entirely sure about that: http://ferrium.org/mantis/view.php?id=7
Can anyone here try getting a ship in game with the latest build? We really need more testers than just me here. :p
And there are a couple more bugs on mantis now btw.
-
How about making them all visible, but highlighting and/or wider the currently selected path?
Ok after setting up the paths, theres several things that need to be fixed.
If you want to keep the spheres, they should not be white, especially when the model is white.
An option to disable the spheres and revert to pcs1 style. The size feature is nice, but not when you trying to first set them up.
-
that's how it is now.
-
I mean like in PCS1.. have all the lines visible and the currently selected path differentiated
-
redownload and see if you are any happier.
-
Definitely better! Much easier to understand :)
One minor feature, when you get a chance. While your editing paths, it would be nice to see all the paths (ideal for error checking). Something like in PCS1, just have blue lines, and blue boxes, no spheres for the unselected paths. For the selected paths, leave as you've got it now :)
-
this things starting to really kick ass.
-
Coming along nicely. Btw, is the non-textured view supposed to render the model fully faceted now ?
-
Coming along nicely. Btw, is the non-textured view supposed to render the model fully faceted now ?
sorta.. while i was playing around i disabled point normals when not in textured and forgot to move em back
-
Having a slight problem with one of Saga's models. What is the scale ratio for PCS2 (is it still 1 to 20)? If so then I've got a strange problem, the model is appearing much smaller than it should be.
-
I really like the new interface, and the rendering is nice and clean. However, I seem to have run into a very serious, and irritating bug.
I converted the model ncrus01, which has about 1.5k polygons. It shows up rendering properly, and I am not aware of any problems until I finish all the turret and subsystem info and then set it up for a test. FRED crashes upon seeing the model, stating "serious model error, resetting 1 normals to 1." Puzzled, I looked at it again in PCS2, with no apparent errors. I have converted many models before and never run into this problem. Upon opening it in modelview, I found that it had a NEGATIVE width. As in, a width of -717. This may or may not be related to the fact that for all normal entries, for the turrets, the default X value was -000000, while the others were just 000000. Both FRED and Freespace both crash when they see the model, and I know there aren't any geometry problems. I can send the model in question if you want.
-
Oh at last someone else has tried to get a model in game. :D
Here - can you create an account and add all that to this bug report?: http://ferrium.org/mantis/view.php?id=7
I didn't think to see what Fred has to say about the models I've tried thus far, - I'll give that a go when I get home. I suspect we may need as much info about this one as possible.
-
I was just noticing that PCS seems to have an odd fliping of the x coordinate, I think this has to do with OGL's coordinate system, and Kaz may have tried to compensate for this in file IO, I'm not sure though. I sent him a message a few hours ago asking him for clarification about this, I am right now rewriteing OGL's projection matrix code to accept a right handed system with things displayed the way you would expect, z going into the screen up pointing up and right pointing right.
-
lol, I hope PCS2 can take over every scrap of modviews use then, cos inverting or shuffling around axes between proggies would drive anyone insane. ;)
It certainly looks like it's well on the way to being able to fully take over though. :D
Oh yes - and on that note at some point it would be very helpful if we could associate POFs with PCS2 and have it able to open them by double clicking on the POF, rather than opening PCS2 and then opening the POF.
-
ah, I found it, POFTranslate it is a function that does nothing but flips the x coord of any vector loaded into file, then flips it back when saveing. the whole reason it's needed is because OGL uses a coordanate system were Z comes out of the screen, were as FS2 uses a coordinate system were Z goes in. Kaz must have decided to just flip the values in the pmf cause he could just flip them back.
ok, I'd like everyone to download (sig) my latest build, and tell me if everything still seems to work and if this has fixed this crash bug (I doubt it, but if he would have forgotten just one vector wrapper it would have been getting fliped). I rearainged the projection matrix to be a little more intuitive for me, and made the flipping of x components unessisary. (and disabled it)
[edit]I just tried it myself, and all the polys are flipped, I was sort of expecting that, but still see if it crashes.[/edit]
-
Wehey, it worked! Well modview still reports a negative X dimension for the bounding box, but I think you nailed the crash part. :D
-
seconded. My test model now loads properly, restoring 45 minutes of POFing work. GO BOB! Now, if you can just absolute-value the bounding box export dimensions...
-
technically OGL is using the standard coordinate space from math and POF and COB are using odd ones
-
well swapping them back and fourth is confuseing, both to us and the user, and liable to cause bugs, I managed to get OGL to display pofs with there native geometry displayed as you would expect, (and also managed to get camera location and orientation). are you dead set on keeping this like this? if you want I'll commit my changes to OGL and you can try and get file loading to work with it. (as in, remove the x flipping)
-
we're not rendering POF's - we're rendering PMFs .. PMF stores information using the standard axis, just like OGL. COB has weird axis, POF has weird axis... i hate working with weird axis
[edit[ i think i just found the bug... it looks like BSP data is being generated off the standard axis instead of off POF's axis
-
what we have now is wierd to me, not to mention it's what our source and destination files are useing, and what all other POF editing programs thus far are using, I think it's what 3ds max uses, so our entire user base (and half our developers :) ) is expecting x to point right, not left.
-
COB isn't using POF's axis
given standard vector A,B,C
OGL + PMF are A,B,C
POF is -A,B,C
COB is B,C,A
-
in terms of what is seen in the model, though its
left, up, forward
I always think of x as right, most other people here do too, I think.
-
exactly..... in POF +X is left....
OpenGL's coordinate system
(http://www.falloutsoftware.com/tutorials/gl/cartesian.gif)
-
ok, I want you to open up a pof, and place a subsystem, now orient the ship such that if you were sitting in the pilot seat everything would be oriented properly (camera behind the ship). if the subsystem's x component is positive, then it will be on the left hand side of the ship.
OGL's coordanant system has z comeing out of the screen this translates to forward being negitive z. if x is right, and y is up.
-
you're used to odd orientation because when i say "right" i mean "looking at the coordinate system from the outside" - ie what that graphic shows
now "right when looking at positive Z" is another thing entirely... and it's what POF is doing IIRC - but not OGL, PMF or COB
-
when I say right I'm talking about the ship, I'm talking about what people are going to be thinking about. in this regard, there are three options, we have the x values flipped (current), we have the z values flipped (wich would be more like what OGL is thinking), or we flip nothing and make a projection matrix that flips it for us.
currently, x in terms of the model, is how far to the left of the ship something is. that seems very counterintuitive to me.
not to mention all this flipping is probably taking up a bit of processing that could be spent elsewhere.
-
and POF and COB's weird ass coordinate systems are foreign to me and i dislike working in them. we can put a little 3D control in the corner of the screen in PCS2 to show you how the coordinate axis are oriented but i'm not going to go through and completely rewrite PMF, COB->PMF, POF->PMF, PMF->POF to use the nonstandard coordinate system
[edit]
just commited changes that should hopefully fix the #07 (http://ferrium.org/mantis/view.php?id=7)
oh.. and FOF uses OGL's coordinate system as well
-
I bet this will get reported as a bug more than once, and I bet it will cause a bug more than once. but it's your call.
I just wanted to officially state that, so we can move on.
ok, so just to make sure we are clear, on the model, x is to the left, y is up, and z is forward?
-
the coordinate system i posted a picture of above is the one being used by PMF
-
and in terms of what you see on the model when you specify coordanants, x is to the left, y is up, and z is forward, this is how you want it, right?
I just undid my changes locally in regard to 'fixing' the flipped x.
the only other option is x is right, y is up, and z is BACKWARD, and that is clearly not what is showing on the model.
-
yes? no?
+x is the models left, this _is_ what you want? right?
that picture you posted shows +x pointing right and +z pointing back, which is NOT what our coordinate system is doing.
-
will you say yes already so I can consider this resolved and get back to work...
-
...well... anyway, raypicking should now be working for all omnipoint data, you just have to double click on the point and it will be selected, I also revamped omnipoint movement, so it should work a lot better now, so holding ctrl down while holding the mouse button down should move the point, and on top of all this I added a data menu, who's sole purpose was to act as an accellerator (aparently the native accelerator table is not quite working on all platforms, and this self documents the features) you can add/copy/delete any item/list without useing the buttons, so you could theoreticaly do 90% of you pof editing work without clicking on a single button.
-
in the off chance that someone has downloaded the raypicker build, I just fixed a somewhat nasty bug that got introduced when a CVS conflict caused one of my files to get reverted and I didn't realise what it had done.
also fixed the menu/keyboard shortcut thingy such that it actually works now (I had forgot to flag any of the array controls other than the one I was testing with... :nervous:)
five posts in a row... that's sad... and it's not like there's a no time between them either... it's like there's only three people reading this :wtf:
-
unless I get some major objections I'm going to remove most of the existing toolbar buttons, the move and rotate buttons realy just aren't very usefull and have two other ways of doing the same thing a lot more intuitively and I need the space for other things, notably options for moving things (plane orientation, alignment and axis locks).
-
That'd be excellent - especially the axis lock. :) The little axes compass in the corner of the 3d window would be great too.
Can't test it till I get home tonight in a few hours, but I wanna know why we've got so few testers in here as well. This sorta functionality isn't time consuming or difficult to test, and there are still a lot of people who use PCS1 currently.
Personally I reckon we'll begin seeing a bigger response once it can begin shifting subobjects around, and also once bug 7 is completely squashed (seen the note in mantis btw - I'll test #7 out as well tonight), but the total lack of current testers is not helping us get there. :\
So, since red is attention-getting:
C'mon peeps! If you wanna see HTL versions of the really big stuff in the future, you gotta help us out at this stage, because this is the tool that will make all that and much more happen! :p
(Actually - it might be an idea if we could get some of the masses of new fans of BTRL to help out. A lot of them seem very eager to help out, and this would be a great way for them to do that. In fact the devs have said they're waiting for PCS2 to convert the battlestar models properly, thus providing said masses with motivation. ;) )
-
it can shift objects around... :(
just select an object hold down ctrl and you can drag models around.
although now that I look at it it seems there are some bugs with that...
-
unless I get some major objections I'm going to remove most of the existing toolbar buttons, the move and rotate buttons realy just aren't very usefull and have two other ways of doing the same thing a lot more intuitively and I need the space for other things, notably options for moving things (plane orientation, alignment and axis locks).
True a lot of those view buttons could be done away with.
One option is to have help>keyboard and mouse - with brief description of each function
You could also have front / side / rear view etc mapped to numpad keys. 7 top, 1 front and 3 side + shift for reverse side.
One way around the mouse zoom problem would be to keep mousewheel and shift+right mouse as is and add Ctrl right mouse to zoom a large amount
-
ctrl+rightmouse is for moving things in the y direction, but I'm not sure what you mean by "a large amount" shift zooming is prety fast, it's a ****-ton faster than hitting the zoom button at least. and honestly, when was the last time you actually used those predetermined orientations, if I was to do anything remotely like that I'd have a dialog were you could type in angles explicitly.
-
just updated fixing movement of submodels, sence I origonaly implemented that the render method was changed, and they were not getting updated enough, and you wouldn't be able to see them relitive to there parents.
-
just updated fixing movement of submodels, sence I origonaly implemented that the render method was changed, and they were not getting updated enough, and you wouldn't be able to see them relitive to there parents.
That explains why I didn't spot ctrl+rightmouse's function.
On the zoom thing, just tried the mvp sath and it worked fine. It seems that if the first view of the model is wrong then the zoom doesn't work fast enough. Looks like two of the pofs I'm using are not set up right.
-
the zoom is progressive, the closer you are the slower it moves.
and that bug only effected submodels.
-
ok, I just uploaded tonight's last build, I improved the movement of omnipoints in the 3d window, double click on somehting to select it, hold down ctrl to move it, left button moves it along the XZ plane right button moves it along the Y axis.
-
ok, I just uploaded tonight's last build, I improved the movement of omnipoints in the 3d window, double click on somehting to select it, hold down ctrl to move it, left button moves it along the XZ plane right button moves it along the Y axis.
Paths look good
Is a Ctrl Z possible - Find I'm accidentally moving stuff with the ctrl
In preferences - the ambient and diffuse colour are not saved on exit.
Is it possible to have a selected and non selected omnipoint colours in preferences?
Double click to select does not update the left hand tree
If a thruster omni is partly buried in geometry (about a quarter) then selecting it from the front up to 45 degrees didn't work. Selecting it from behind or side was ok.
Textures work fine for mvp models with path set.
Not working for model with textures set to a mod root and mod map dir and also with textures in directory with the pof .
If the mod uses vp's for textures then everything works as expected.
-
the observer in that image should be considerd to be looking in the negative Z direction.
let's place the observer inside a fighter in that coordinate space - the observer is the pilot
+X is right
+Y is up
+Z is forward
-
Not working for model with textures set to a mod root and mod map dir and also with textures in directory with the pof .
as posted three or four times
foreach <path> in <texturepaths>
search <path>\<texturename>.<(ext list)>
search <path>\data\maps\<texturename>.<(ext list)>
search <path>\VPs .. VP folder data\maps for <texturename>.<(ext list)>
-
my most recent builds allow for relative paths to be set, all I did was set the working directory to the directory were the model was loaded from, so just entering .\ will load from the directory the model was loaded from, ..\maps should load from the maps location (...\ should also load from the maps directory IIRC). of course it only seems to load from the root location.
we are considering an undo buffer.
ambient and diffuse should be getting saved, are your texture paths getting saved?
I already plan on having a color selection dialog for rendering colors.
it's posable you were selecting another point you didn't see, the ray picker will select the closest point that is within it's rendered radius (paths use log of there radius, cause some of them are huge).
the observer in that image should be considerd to be looking in the negative Z direction.
let's place the observer inside a fighter in that coordinate space - the observer is the pilot
+X is right
+Y is up
+Z is forward
ok, so the observer is in the cockpit of the fighter, looking towards the front of the ship sitting upright.
in this case the orientation of the ship relative to the observer should be like how I have attached, it's zoomed back so you can see the rest of the ship. as you can see a positive x is on the left, not right. this is because OGL's coordinate system has Z coming out of the screen (toward the viewer), but our model is constructed with positive Z pointing toward the front of the ship (away from the viewer if they are in the ship). because we have set positive z to be forward in model space, positive X must be to the left in model space. but, just look at the picture, it's on the left hand side of the ship.
ok, I want someone else's opinion on this, am I crazy here or it the sphere in the picture not on the left side of the ship when it has a positive x position.
all of this is moot of course, as working with Z pointing backward would be just as inconvenient for me as x pointing to the left, and I've already done a ton of work trying to get the ray picker working in the backwardly system, so I'm not going to advocate me having to re-write all that code just as I get it working. I guess I just want it acknowledged as being the way it is.
[attachment deleted by admin]
-
my most recent builds allow for relative paths to be set, all I did was set the working directory to the directory were the model was loaded from, so just entering .\ will load from the directory the model was loaded from, ..\maps should load from the maps location (...\ should also load from the maps directory IIRC). of course it only seems to load from the root location.
we are considering an undo buffer.
ambient and diffuse should be getting saved, are your texture paths getting saved?
it's posable you were selecting another point you didn't see, the ray picker will select the closest point that is within it's rendered radius (paths use log of there radius, cause some of them are huge).
Heh. I don't think it has a problem with saving settings. It does have a problem with where it saves it. Just did a search for pcs2.ini - I've only got 12 at the moment :rolleyes: I know that system was chosen due to texture path load time, but starting pcs2 in one directory and ending up in another directory will cause confusion.
How much work is it for pcs2 to be able to load a pof using "open with" from explorer? It will help in replacing modelview as the default pof program
Thanks - the .\ path works well ;)
For selecting the omnipoint - none were huge, and no other omnipoints were behind it. Not sure why being partly buried in the mesh would affect it, as the sphere midpoint was definitely outside the mesh.
-
CWDing may (And probably will) cause problems when saving pcs2.ini
-
@Water:it shouldn't effect it at all considering the only thing being looked at is the position and radius of omnipoints, are you sure no other point got selected? I've had that happen a few times.
I just uploaded a new build with a color options dialog, you can specify all colors for all states of all relivent editors.
@Kaz:were is the relivent code for saveing the ini? I thought it was given a file handle of some sort.
-
just uploaded a version that you should be able to associate POF files to, it also has a new icon, I wasn't very inspired, but it needed something, if someone can come up with something better I'll be willing to consider it (the same goes for tree node icons).
[edit]just uploaded a new build I think I got config saving fixed, it was really bad with the file association stuff[/edit]
I seem to be more than half the posts in this thread, are people just that uninterested? I find that hard to believe, it's getting to the point were this thing is getting more powerful that any pof editor we ever could have dreamed of a few years ago, but yet no one posts... I remember when I'd post something a while ago, and there'd be three or four responses before I could refresh the page, but the interest seems to be gone now... well at least that means it was nothing personal with proximus, I guess the FS modding scene is actually dieing after all these years...
maybe we should consider infinity suport or some other games...
-
y'know, maybe it's time I let this sit for a while, I've been neglecting BWO for far too many months now.
-
@Water:it shouldn't effect it at all considering the only thing being looked at is the position and radius of omnipoints, are you sure no other point got selected? I've had that happen a few times.
I just uploaded a new build with a color options dialog, you can specify all colors for all states of all relivent editors.
Now that the tree updates on the left when you double click an omni, the problem seems to have gone. With the amount of colour options you have provided I won't be able to complain about choice.
just uploaded a version that you should be able to associate POF files to, it also has a new icon, I wasn't very inspired, but it needed something, if someone can come up with something better I'll be willing to consider it (the same goes for tree node icons).
[edit]just uploaded a new build I think I got config saving fixed, it was really bad with the file association stuff[/edit]
Woot!! Thanks - Now set as default pof viewer
I seem to be more than half the posts in this thread, are people just that uninterested? I find that hard to believe, it's getting to the point were this thing is getting more powerful that any pof editor we ever could have dreamed of a few years ago, but yet no one posts... I remember when I'd post something a while ago, and there'd be three or four responses before I could refresh the page, but the interest seems to be gone now... well at least that means it was nothing personal with proximus, I guess the FS modding scene is actually dieing after all these years...
Well Proximus was never going to have a large volume of users outside the graphics area, but PCS2... should.
Sounds like you're in the middle of an coding/(art) crash - where you do magic for a period of time and then you hit rock bottom for a week or two before picking yourself up again.
One more request - is it possible to get a temporary build that can generate a log file related to texture loading? I'd like to find out why/where my texture loading problem is. I used Maja to drop a .vp with all textures in a mod root just to get textures to show.
-
what exactly do you want this log to show?
-
Just an inactive time of year I think - I only finished my uni exams in the past hour, so now I'll really be able to test this more thoroughly at last. :D
I'm going to post something over on game warden to try and snag some BTRL fans to help test BTW. I've checked with Karajorma, and I think we should get at least a couple from there (might even make some new modders too).
Couple of other things:
- The open from explorer thing works perfectly - I've switched over now as well. :)
- The colours selection panel seems to also work perfectly - though I've not yet gone through everything.
- I hadn't noticed the subobject translation (I don't think you actually mentioned that it worked for subobjects btw - only the editing points. ;) ), but that's awesome!
Two little things about it though:
1) Might it be possible to have the selected subobject highlighted in some way? A toggleable bounding box or radius or something? There's currently no way to tell what object you have selected (clicking or ctrl-clicking doesn't help) until you irreversably wave it around a bit.
2) Will the abilities to rotate and maybe even scale stuff be coming in as well?
3) For all this movement ability, it really needs some co-ordinate/orientation/scale manual data entry fields to allow for precision work. Would that be possible?
-
The fact that PCS2 works on my PC at work, but not on my home PC is somewhat hindering my testing capabilities.
-
"I don't think you actually mentioned that it worked for subobjects btw - only the editing points."
well technically it is still the editing points, I have the omnipoint code hooked up to the submodel offset, and I tell the omnipoints not to draw themselves.
and yeah I keep forgetting to put the offset editor in, it'll be a matter of a few minutes, if you had come in a few hours ago I'd have jumped right on it, but I got to sleep now.
now as for rotation, unfortunately the POF file structure does not natively support orientation, and sence the PMF file structure was losely based upon the POF file it doesn't either, it's going to be a while for that cause we will need to modify both file formats (or at lease the PMF) in addition to the coding of the rotation stuff. now scaleing is doable in the measured-in-weeks future.
I'm thinking about having a wire frame overlay on the selected object, that's how I did it in Aurora, and it worked well.
and Col., how does it fail? and why don't you...
(http://freespace.volitionwatch.com/blackwater/mantis.jpg) (http://ferrium.org/mantis/)
-
Actually, a couple of additional things:
4) Are there plans to get alpha maps/glow maps/shine maps/env maps working?
5) Could I just make a request that we be able to change the resolution textures are displayed at? Currently it looks approximately 256 size. :\
And ok - that's cool. Just the ability to shift stuff around like this is lightyears ahead of everything previous. :D
Edit: Never mind about #5 - I see Bobs reported it in Mantis. :)
-
and Col., how does it fail? and why don't you...
(http://freespace.volitionwatch.com/blackwater/mantis.jpg) (http://ferrium.org/mantis/)
Because it just fails to start with the terribly informative message : "This application has failed to start because the application configuration is incorrect."
-
well, take a screen shot of the error message and post it in mantis, come back a few hours, or a day later and try what we say. you are probably not the only person to get this error so it'd be nice if we could fix it.
I was sort of looking around to see if there was some way I could tell if a texture had an alpha channel or not, I'm an OGL novice, so I'll have to yeild to Kazan on that one. as for the small texture thing, I just noticed that myself, I tried finding out why it was doing that, but I couldn't, so I made up a bug report and gave that to Kaz also.
I'd say the big thing we are missing right now is chunk import/export, I took a stab at that tonight, but I couldn't figure out how to get the loading code to work (kaz did some freaky multi-threaded stuff with it to make it run faster, and I have zero multi-thread experience)
-
That's exactly the whole error message, it's a standard Windows message. My googling has given me the suspicion that it has something to do with missing DLLs. My home machine is running SP1, while the machine at work has SP2, although Kaz stated that this has nothing to do with it.
-
you should still report the bug so we can attack it in an organized fashion, figure out which DLLs you are missing and were to get them from. thats the whole point of having a bug tracker.
-
actualy, try running this (http://freespace.volitionwatch.com/blackwater/vcredist_x86.exe).
-
what exactly do you want this log to show?
Hmm.. probably would show you what you already know. It was a bad suggestion, please skip it
For looking in \models directories found that your suggestion of ..\maps\ is usable. It does need the last \ or it won't work.
search <path>\<texturename>.<(ext list)>
search <path>\data\maps\<texturename>.<(ext list)>
search <path>\VPs .. VP folder data\maps for <texturename>.<(ext list)>
Yes
No
Yes
In other words, it just checks the directory its pointed at, but no deeper.
-
search <path>\<texturename>.<(ext list)>
search <path>\data\maps\<texturename>.<(ext list)>
search <path>\VPs .. VP folder data\maps for <texturename>.<(ext list)>
Yes
No
Yes
In other words, it just checks the directory its pointed at, but no deeper.
don't presume to tell me what the code i wrote does and does not do
http://alliance.cvs.sourceforge.net/alliance/pcs2/tex_ctrl.cpp?revision=1.21&view=markup
i know the search order of my code.... now if it's bugging out searching that that.. that's another thing entirely - but don't tell me it isn't doing it.
[edit]
he bob
wxCmdLineParser (http://www.wxwidgets.org/manuals/stable/wx_wxcmdlineparser.html#wxcmdlineparser)
and your CWD stuff did break pcs2.ini - so i had to pull it out
-
I was sort of looking around to see if there was some way I could tell if a texture had an alpha channel or not, I'm an OGL novice, so I'll have to yeild to Kazan on that one. as for the small texture thing, I just noticed that myself, I tried finding out why it was doing that, but I couldn't, so I made up a bug report and gave that to Kaz also.
i don't know how to do that either.... google to the rescue
-
don't presume your code does what it's suposed to do, he's telling you that middle case there doesn't seem to be working, that sounds like a bug report to me. PCS1 was practically famous for being imposable to get textures to load for some people.
are you sure it isn't doing
search <path><texturename>.<(ext list)>
search <path>\data\maps\<texturename>.<(ext list)>
search <path>\VPs .. VP folder data\maps for <texturename>.<(ext list)>
it's a very minor diference, thinking the <path> ends in a '\' in the first case but adding one to it in the second, I have to RUN to work right now, and that code is quite complex for what it does, so I can't exactly check it my self at this exact second. just a thought.
-
it opens the directory and list walks it :P
i was going to write a HUGE debug dump log that prints out all sorts of information on that - full list of files found.. then hit matches
-
new build - debug build included in this pair will generate a pcs2_txtsrch_log.txt upon it running texture load so if you need to debug your texture paths use it
http://ferrium.org/media/pcs2-alpha-20070625.zip
-
new build - debug build included in this pair will generate a pcs2_txtsrch_log.txt upon it running texture load so if you need to debug your texture paths use it
http://ferrium.org/media/pcs2-alpha-20070625.zip
Thanks - downloading now. I should be able to find out why /data/maps search doesn't work for me. Be tomorrow for results.
-
The standard build starts up fine.
The debug build fails with dialog box showing
>path to app
>This application has failed to start because the application configuration is incorrect.
>And reinstalling app may fix problem
Does it need other support files/librarys to run?
2am - gotta go
-
we don't know why that happens
-
i'm going to stop including the DLLs in every build.. if you want them here they are: http://ferrium.org/media/pcs2dlls.zip
-
hey bob.. for future render usage - i want to setup "context information" - every time the selected editor changes the "render context" needs to be set
IE what the active chunk is, what the active data in that chunk is (ie glow array i, glow point j) etc
-
actualy, try running this (http://freespace.volitionwatch.com/blackwater/vcredist_x86.exe).
This fixed the problem, thanks.
What exactly did it install ?
-
visual studio 8 dlls for the C-Runtime Library
:wtf: i hate how m$ does that :mad:
-
Well at least we know now what the problem was.
As for PCS2: I've run some ready-tp convert COBs through it, no crashes so far and smoothing looks pretty much like the PCS1 results. Turret-auto-generation is not yet implemented, right ?
Also, textures in /data/maps/ are not found, no matter what path i enter in the preferences.
Textures are found, but it's necessary to add a '\' at the end of a path. If browsing through the tree and then clicking "OK" and adding that path results in a path wihtout '\'
-
turret autogen is implemented... is it not working?
-
turret autogen is implemented... is it not working?
So it would appear, unless you changed something in the required naming conventions from PCS1.
Also, when using DDS maps, PCS2 seem to apply one of the lower mipmaps even to LOD0, instead of the full resolution map. Is that a bug or a feature ?
-
are oyu using the latest build?
-
are oyu using the latest build?
Ah, I wasn't (I was using the one from Bob's sig).
Now the latest build displays the proper mipmap level, but still no luck with turret autogen.
-
lemme see the model
oh... and it appears i've finally resolved #07 (http://ferrium.org/mantis/view.php?id=7) - just used the HTL zeus converted with PCS2 in game.. no crash.. lighting fine.. collision detect fine
-
lemme see the model
There you go. I verified that the turrets get generated correctly with PCS1.x
[attachment deleted by admin]
-
haha i'm a dork.. i forgot to implement the second half of it :P
[edit]
oh.. no.. i did implement it.. there was a bug in kaz_string::operator+=(kaz_string &other)
-
Is there some certain way the model is supposed to be formatted? I exported the model from my modeling program to .3DS, then into Max, where I welded all the vertices and applied the textures. I exported from there to .3DS, which I then used 3D Exploration to save the model as a COB. PCS2 conversion works fine, except the models have no collision detection. Am I just doing something wrong?
-
it's hierarchy compliant?
then i'm probably still expiriencing problems with BSP compilation which i thought were fixed (*grumble*)
[edit]
confirmed... i'm done working on it for the day.. so i'll work on it more another day
third build for the day http://ferrium.org/media/pcs2-alpha-20070625c.zip
-
Don't mean to bother, but where can I find the data to make sure the model is hierarchy compliant (so we can be sure it's the program and not just the model).
-
convert it with PCS1 and use that pof
-
Splash screen yay !
Turret-autogen is working now.
The "COB scaling factor" in the preferences is not working. I've mantised it for great justice (also becasue I've just made an account)
-
Yay splash screen. The model does seem to work better, there are still sizeable chunks that can be shot through, but at least 50% of the model is solid now.
-
I updated my code with everything Kaz has done today, and updated my sig build appropriately.
-
hey bob.. for future render usage - i want to setup "context information" - every time the selected editor changes the "render context" needs to be set
IE what the active chunk is, what the active data in that chunk is (ie glow array i, glow point j) etc
not sure exactly what you want me to do, the omnipoint stuff handles both the rendering and editing of this data, if you want to know this information you can usualy figure it out via wxGL_PMFCanvas::omni_selected_list, wxGL_PMFCanvas::omni_selected_item, and main_panel::control_panel->chunk_type. the omnipoint system was set up for maximum flexibility and adaptability (so adding new chunks in the future should be super easy), so it shouldn't need to know any more information that what it gets from the omnipoints struct, though I supose it wouldn't hurt if it did know.
what do you need this for, and/or what would you like changed?
-
there are things that aren't pointed based - textures, shields, etc
-
ah, yes... that's a good point, how would you like this to work then? just a function that gets called whenever the selected chunk is changed?
-
I just had a minor thought, would it be difficult to have a small sub progress window similar to the one you have for the import model loading for saving of sub models when saving as a pof? would display how far on the currently saving subobject the BSP compilation is, not completely sure how you would judge progress there though.
it was just something I thought of while I was waiting for a model to compile.
-
ok, well, I just updated my build, you now have full model import options, you can import one chunk or everything, and you even have a rather fully featured subobject import as well
(:jaw:)
which is the only way to add subobjects currently (you 'should' be able to import directly from COB in addition to pof or pmf), unfortunately removing subobjects is still not posable, due to the fact that there are a _lot_ of interdependencies in regards to a subobject, it's position, the hierarchy, and ANY data that uses subobject number as a reference.
chunk Import is accessed through the load button on top of the editor (save still does nothing), and global import is a menu option under file.
BTW do we (everyone reading this) really want chunk export? is it really useful? I know I did it in Aurora, but it was mostly because I figured I could do it relatively easily and thought it would be cool, but now that the novelty isn't there I can't realy think of any situation were it would be very useful.
-
chunk export is unimportant and adding hooks to judge progress into BSP compilation would make it take yet more time
-
I don't think it's add that much, would it? I mean it's just a simple UI call, and I'd be willing to wait longer if it meant I knew how long I was going to have to wait. well, you should provide some feedback to the user to let them know it's still working and hasn't locked up.
I really don't feel like writing export, but I wanted to see if there was some irrational overwhelming demand for the useless feature before I dumped the idea permanently.
-
someone requested export i think... but it's not an important feature to me... go ask in the feature request thread
it would probably add a lot because each time it changes is a GDI redraw on the UI plus it's difficul to really say at any one point - because first you're generating a tree... then you're writing it. No way to guess completion on the first.. second i atleast know how many bytes should be written - but again it's a recursive function.
-
Import data would do a similar thing anyway wouldn't it? I can't really think of a good use for chunk export.
Anyway the subobject import is great! This is going to be incredibly handy for making gun count varients on already poffed ships and lotsa other stuff. :D
The global data import seems to work fine as well, but it'll need more testing to be sure.
I'm currently still experimenting with conversions and collision detection - because I'm getting a lot of problems there still.
-
Only problem I found during testing was a crash if you click on subobjects with no model loaded (pre-existing). Didn't think it was important before , but may get used with the import ability. Otherwise it worked without any problems. :yes:
Export, with what you have added, pof, pmf, and cob are all that is needed.
-
new build - debug build included in this pair will generate a pcs2_txtsrch_log.txt upon it running texture load so if you need to debug your texture paths use it
http://ferrium.org/media/pcs2-alpha-20070625.zip
Got the debug build to work.
Your search is logging the textures in <path>/data/maps but doesn't generate a hit.
-
then that means it didn't see the texture matching the name there... check that the ile is actually there - if it is see if it got missed by the dir wind - look at the list of files pumped out
-
[edit]
nope.. i was wrong
[edit]
i'm stumped.. collision detection problems isn't because of an axis translation problem.. all the positions are correct, polygon norms are correct, etc... i don't get it
-
then that means it didn't see the texture matching the name there... check that the ile is actually there - if it is see if it got missed by the dir wind - look at the list of files pumped out
By "logging the textures" , I mean it is listing the names of the files that should be generating a hit.
-
it's showing the filenames in the big list of files... but it's not showing them being found?
what are the filenames and what type of file are they
-
i think i've isolated WHERE the bug is.. and half solved it.
take a model and convert it in PCS1 and PCS2 .. open both in PCS2 and enable BSP debug... compare the red boxes (sort norms) you should see more in the PCS1 compiled one (there are actually less being made by PCS1.. but they're of MUCH higher quality) - code on my machine has that siginficantly cleaned up.. now i just need to find the other little problems with it
-
check the build in my sig kaz, the last tree item might prove useful, though I'm not committing any of that unless you want me to.
-
what's it supposed to do?
-
look for the BSP DEBUG item in the tree. you can simulate collisions with a point and it will only draw the bboxes that are pertinent to that collision test. and you can limit how deep it goes into the recursion with the depth parameter.
one thing I've noticed with it is the sortnorms seems to fill up the same voluem for the most part, over and over, 50% seem to have a edge at the center, for example, most pofs, you don't see them pile up right on top of each other like that. it also seems like child bounding boxes go a lot further outside the parent than they should, like there will be a bounding box that covers everything on the right, then the child of thab box will have everything in the middle (both left and right)
-
it's showing the filenames in the big list of files... but it's not showing them being found?
what are the filenames and what type of file are they
You are really hard to convince. This is my last test on this issue.
Tested tga vs dds - not relevant
Tested files with various names - not relevant
<path> is explicit c:\mtest\data\maps\
c:\mtest\data\maps\ Files
c:\mtest\data\maps\data\maps\ Files
c:\mtest\data\maps\ VPs
File matched: c:\mtest\data\maps\v_atkcarrier.DDS
c:\mtest\data\maps\Arwing-glow.DDS
...
...
c:\mtest\data\maps\v_atkcarrier-glow.DDS
c:\mtest\data\maps\v_atkcarrier-shine.DDS
c:\mtest\data\maps\v_atkcarrier.DDS
...
...
c:\mtest\data\maps\yellow_glowpoint1.DDS
<path> root only c:\mtest\
c:\mtest\ Files
c:\mtest\data\maps\ Files
c:\mtest\ VPs
c:\mtest\data\maps\Arwing-glow.DDS
...
...
c:\mtest\data\maps\v_atkcarrier-glow.DDS
c:\mtest\data\maps\v_atkcarrier-shine.DDS
c:\mtest\data\maps\v_atkcarrier.DDS
...
...
c:\mtest\data\maps\yellow_glowpoint1.DDS
-
no water, i am being very clear because lack of clarity results in bugs not being fixed
bobboau: i noticed that about the snorms too and already fixed it in code, but that didn't seem to fix the collision problems.
[edit]
using your BSP debug stuff i figured my outermost bounding region may be to snug against the model
-
Bob; that thing is great! Can I safely assume blue = not in this box, red = in this box and green = collision? It's showing a massive difference (far fewer boxes of any type) between the PCS2 generated models and the previously converted ones.
-
it's just not drawing all the boxes. green = bbox, the rest are snorms (containing and not containing the sphere)
not drawing all the boxes actually annoyed me a fair bit i was like "Where the hell.."
it was useful to play with for a few minutes.. but it didn't find me the solution
-
yea, red is a sortnorm you colided with blue is a sort norm you tryed to colide with but failed to, and green is a bbox, hitting a bbox usualy means there will be a colision (exept when they are around 45 degreeish geometry)
I had actualy forgot about the blue box.
try moveing the test point onto an area were you are haveing colision problems, and if you can't get a green box to apear then that would be the problem (though it could just be very hard to see)
-
no water, i am being very clear because lack of clarity results in bugs not being fixed
ok - understand
-
ok - understand
which file is the one that should be being hit, but isn't? (that log output from builds i post after this point will have more detail)
Bobboau: i tried it.. it was giving me BBox hits in spaces that FS2 wasn't... so it's not going to help
-
PCS is driving me crazy lately..both verisons..
Older one keeps SHOWERING me with "stack overflow - too many polygons in same average location" and PCS2 keeps messing with the bounding/collision boxes and re-scaling of my friggin model! :mad:
-
Almost all of my models have a stack overflow on PCS1, however with PCS2 they actually do get converted, minus collision detection (and in one instance a couple missing triangles). So there is progress, it's the collision detection generation bit needs work.
-
Kaz just supposedly fixed that. I think my sig build has his new code. try it.
-
Nope, no detection using that build.
-
about time this got fixed
try testing the collision detection with this build: http://www.ferrium.org/media/pcs2-alpha-20070627.zip
(make sure to open from the COB not just reopen the POF)
VA reported the collision detection fixed in this build. If you are having problems still with this build i need you to post the model, post a table entry for it, give me a copy of the .pof so i can import gunpoints etc and a mission to test.
-
Bobboau, I've gone through the path data for all original destroyers, corvettes and cruisers and have worked out the average trends for subsystem and turret paths.
Subsystems:
- The first vert (the big one further away) should have a radius of 6 x that of the subsystem itself. Your vectoring system seems quite good, and the distance of this vert from the subsystem should be 1.2 x it's own radius.
- The second vert (small one close in) should have a radius of 0.3 x that of the subsystem. Again, the vectoring system is fine, and the distance should be about 0.9 x the subsystem radius.
Turrets:
- The first vert should have a radius of 30 x the radius of the target subobject. The 'down-the-normal' vector is fine, and it should have a distance of 1.2 x it's own radius.
- The second vert should have a radius of 0.7 x the radius of the target subobject. Again, the vector is fine, and here so is the distance.
Docking I've not looked into, but since there should only be one of them anyway people shouldn't rely on an autopath to get it spot on for them. ;)
-
ok so
path.verts[0].radius = model.radius*30.0f;
path.verts[1].radius = model.radius*0.7f;
path.verts[0].pos = model.offset + turret.turret_normal * (model.radius*1.2f);
path.verts[1].pos = model.offset + turret.turret_normal * (model.radius*0.7f);
and
path.verts[0].radius = spcl.radius*6.0f;
path.verts[1].radius = spcl.radius*0.3f;
vector3d n = MakeUnitVector(spcl.point);
path.verts[0].pos = spcl.point + n * (spcl.radius*1.2f);
path.verts[1].pos = spcl.point + n * (spcl.radius*0.9f);
that is what you wanted?
that's what's in my sig.
although I don't think your going to like it...
-
ok, my sig has been updated again, now PCS2 has copy/delete capabilities for subobjects (in addition to the import from file).
and a shield "editor", though it doesn't allow editing, it will let you look at the shield mesh.
-
Just one request - add POF SCALING PLS!!!
Just a simple scale factor that would multiply all points with the modifier?
-
that will be the first thing implemented when I start working on geometry editing.
-
:) You made me a very happy man :nod:
-
geometry edit is a 2.1 feature
-
n'other update, movement constraints and axis locking.
-
for the love of god people, I only have three days to code before I have to go back to work for another week, work with me!
-
we need more testers... lemme see what i can do to scrounge up more!
-
just added selected texture highlighting.
I'm literally jumping in my seat trying to think of things to implement/improve/fix.
-
yup, you're the bomb bro
-
ok, untill I get something else I'm going to work on... a geometry filter that will fix convex polygons (and polys over 20 points).
it's non-critical, easy to remove if it doesn't work and has a big payoff if it works.
-
there's a function floating around to triangulate convex pcs_polygons .. i think it's in pmf_bsp_funcs.cpp
-
yeah, but triangulating leads to suboptimal colision detection. FS collides on a per poly basis, if you revert geometry down to simple triangles it will not be able to take advantage of polys of a >3 vert size.
-
hold it, I found something better, I'm gona remove the triangulated restriction from shield meshes.
well I'm gona do that first anyway.
-
pshh, that was too freaking easy, (check over pcs_pmf_cob I just committed it)
now back to the geometry filter...
-
triangulated requirement for shield meshes is a hard-req of POF.... so are you triangulating when generating the pof?
-
yeah,
well actually triangulating it when reading the COB
-
ok, I think I got it, the only thing that I wasn't sure to do with was when there was only one convex vertex, I just split between that and the far end of the poly, figured there was a good chance at least one half would be concave.
I've given it some horendus geometry to try and convert and it produced something that looked good in all cases I tryed.
I'm going to commit, if anything is found bad with this it is the only thing in this commit and it can be disabled by comenting one line in pmf_bsp_funcs.cpp (the call to PCS_Model::filter_geometry)
-
ok, I would really like it if someone would try to make some geometry that didn't convert well with this. keep in mind it doesn't fix non-co-planar polygons... yet...
-
ok, now it does fix non-coplanar (this will ensure good collision detection in addition to making the model look good)
try to break it, I dare you!
-
I'm sure I can find something :)
BTW, Kaz, VA got my model to convert properly, but he had to open it in TS first and then save it as a COB thru there (i.e. it doesnt work using a 3DE generated COB). I haven't been able to try it myself, though, until I get my main machine back.
-
I just made an update, there was an odd case that would cause the converter to lock up, I took into acount when the splitter function was asked to split a poly along the ith and i+1th vert exept when i == the last vert in the poly. if you get something that locks it up try my sig again.
-
Model with group detail 0 with all meshes in child groups gives 0dimension bounding boxes (right pic)
-Viewpoing ends up in model with no ability to pan or zoom model. (or is this the wrong way to set up the model?)
Model with a mesh as part of (group Detail 0) works well (left pic)
(http://www.game-warden.com/forum/imagehosting/95846860a6682725.jpg)
The 3 lock buttons (X, Y and Z) are excellent. Which make the constrain xy etc redundant. Makes it confusing.
Suggestion remove constrain buttons and convert buttons to front, side and top view (if possible)
Wireframe overlay for both objects and textures works very well. Is it possible to have the overlay colour as a colour in settings - It will make the wireframe mode more useful.
-
left is how I've always set mine up.
movement constraints and axis locking work in diferent ways, some situations you will want to move in just one axis, some situations you will want to move along a different plane than xz. they work together, but they have very diferent functions. you don't want to be locked into only the xz plane do you?. if I had to get rid of one it'd be the axis locking cause the movement constraint is a lot more powerful. especially with the fact that the right button will opperate in the one dimension that the left does not.
I can probably add the wireframe colors into the color options.
-
I have a request for the geometry editor - some way to orientate the model would be great (i.e. flip model 90 left/right/forward/back, flip horizontal, etc).
-
left is how I've always set mine up.
movement constraints and axis locking work in diferent ways, some situations you will want to move in just one axis, some situations you will want to move along a different plane than xz. they work together, but they have very diferent functions. you don't want to be locked into only the xz plane do you?. if I had to get rid of one it'd be the axis locking cause the movement constraint is a lot more powerful. especially with the fact that the right button will opperate in the one dimension that the left does not.
I can probably add the wireframe colors into the color options.
Ok thanks
Thought about it and realized that different icons may solve my problem - Would you mind if I did some icons for the constrain and lock buttons? And if so what size?
-
Dude, you're implementing new stuff faster than I can test it - no fair! :p
Not so much a bug as it is a missing feature - if you try and convert a model that would generate a 'you forgot to group those objects message' in PCS1, now just nothing happens. Could we get a nice and informative error message instead? It's one of the most common problems people have had with PCS1.
------------------
As for the autopathing, it's nearly working right, but I think you slightly misunderstood the positioning distances I quoted, and I just realised some maximum caps would be good . :) Instead of this:
path.verts[0].radius = model.radius*30.0f;
path.verts[1].radius = model.radius*0.7f;
path.verts[0].pos = model.offset + turret.turret_normal * (model.radius*1.2f);
path.verts[1].pos = model.offset + turret.turret_normal * (model.radius*0.7f);
path.verts[0].radius = spcl.radius*6.0f;
path.verts[1].radius = spcl.radius*0.3f;
vector3d n = MakeUnitVector(spcl.point);
path.verts[0].pos = spcl.point + n * (spcl.radius*1.2f);
path.verts[1].pos = spcl.point + n * (spcl.radius*0.9f);
It should be:
path.verts[0].radius = min((model.radius*30.0f), 1000); //Capped at 1000 - took a guess at the syntax)
path.verts[1].radius = min((model.radius*0.7f), 100); //Capped at 100
path.verts[0].pos = model.offset + turret.turret_normal * (path.verts[0].radius*1.2f);
path.verts[1].pos = model.offset + turret.turret_normal * (model.radius*4.0f); //What you originally had
and then
path.verts[0].radius = min((spcl.radius*6.0f), 1000); //Capped at 1000
path.verts[1].radius = min((spcl.radius*0.3f), 100); //Capped at 100
vector3d n = MakeUnitVector(spcl.point);
path.verts[0].pos = spcl.point + n * (path.verts[0].radius*1.2f);
path.verts[1].pos = spcl.point + n * (spcl.radius*0.9f);
And that should produce an appropriate cone. :)
------------------
Also, might it be possible at some point to allow an orthognal view option? This combined with the axis constraints would be incredibly useful for accurate positioning of elements.
Edit: Fixed stupid copy&paste mistake in code.
-
Just an observation
File size seems to be larger under pcs2.
Under pcs1 - 34.1mb. The same model with pcs2 - 48.6mb
-
(http://www.game-warden.com/forum/imagehosting/95846860a6682725.jpg)
the right-side is a violation of geometry rules
files are bigger because PCS2's BSP compiler is more thorough.. though i took out an optimization because i thought it was causing problems so i need to put it back in
-
Not so much a bug as it is a missing feature - if you try and convert a model that would generate a 'you forgot to group those objects message' in PCS1, now just nothing happens.
didn't think of it.. easy to put in (didn't think anyone would NEED that message)
-
It's by FAR the most common problem new modders have with PCS1, since they can't work out what it means. A message like
"Ungrouped object! There is a piece of geometry in this file that does not have a light or subobject glued to it. (This usually occurs when PCS encounters an isolated piece of geometry that is not attached to anything in the hierarchy, such as a test hull for conversion or a forgotten piece of your ship lying about your workspace)"
or something better (since it's a little tricky to describe accurately - maybe a link to a wiki page or something) would help a lot in that regard?
-
actually looking at the code i DID think of that message
if (InputFile.Group_Count() < 1)
return -1;
so.... you must have had a group in your file that didn't contain geometry
-
Just tested, but nope - there wasn't any group at all in the file, just a sphere with UV map and texture. PCS2 just sorta started to load and then stopped with no message.
-
hmm.. it should be triggering a popup window.. i'll look later
-
i put back in the optimization for sortnorm regions that contain exactly two polygons.. though in a probably-slightly-safer way - pls tell me if future builds break geometry again.
-
I'm getting a bounding box of 0,0,0, for three seperate models I've tried to convert. It's only resetting the bounding box in the latest builds. The geometry and heirarchy for one of those models converted properly with PCS1. Is there a simple thing I'm forgetting or should I mantis it?
In PCS2, the models all show the proper bounding box in the editing window, but the model crashes FRED and shows up as 0,0,0, in modelview.
I'd like to add that the missing triangle problem HAS been resolved as far as I can tell, and no more flipped X dimension.
Great stuff, though. PCS2 is progressing quickly! I have a suggestion as well: Put the name of the model in the top bar, so you can see the modelname easily if you have multiple instances of PCS2 going. Because of the icon, we know it's PCS2, so we don't need it to repeat it again. It'd be more useful for it to say "fighter01.pof - PCS2" in the taskbar instead of "POF Constructor Suite 2".
-
ok, just updated the sig, fixed a few bugs, modified the auto-path (those values seem to work much better) and added an orthographic projection option.
though I'm still working out some bugs with the ortho.
-
ok, I think I got the ortho problem mostly solved.
-
updated, now with wireframe color options.
-
Thought about it and realized that different icons may solve my problem - Would you mind if I did some icons for the constrain and lock buttons? And if so what size?
didn't notice this till just now, if you can make icons better than the ones I have for anything includeing the executable icon, tree icons, or tool bar icons I'll use them. the tool bar seems to like 24x24, {212,208,200} is the transparent color for them
-
Grr...I tried converting hte hybrid with the latest version..it converts it allright, but chrashes during saving!!!
-
Exelent! a reproduceable bug!
(http://freespace.volitionwatch.com/blackwater/mantis.jpg) (http://ferrium.org/mantis/)
be sure to include a copy of the COB!
-
i'm pretty sure i had it remembering the open file... but that got kobashed somehow ... making it remember the open file name should be trivial... updating the file name on title bar marginally more difficult
-
Where is the collision mesh thingy made? during COB import or when exporting to POF?
-
exporting to
cob pof for the first time.
-
when exporting to POF for the first time[ after geometry is modified], not cob [and on any POFs opened that were generated by versions of compilers i don't trust - IE any POF not built with PCS1 compiler 1.3.4, V's compiler, or right now PCS2.. though that really shouldn't be trusted]
-
I meant to say pof...
-
Kazan or Bobboau, you might want to bring the forward clipping in the viewport closer to the viewer. When I tried zooming in on a model it started clipping. (I bet it was because i forgot about the new conversation ratio).
Also when I switched to Thrusters (I'm converting a model right now) the background switches to white (then another time to light blue) are you remember to restset the background to black?
-
it probably was, that's what it usualy is when that happens to me. (it'll only happen after I reset the config. obviusly) try setting your conversion scale ratio to 20 and see if it's more acceptable to you.
you mean the... the screen in the back gets set to something other than black?
are you sure you don't just have a bizarrely huge thruster glow?
-
had a thought while hunting down why saveing to POF hangs some times, actualy two, the first is you should add a handeler for the stack overflow exeption, something that terminates the thread and *set's the external flag to false* i.e. IsRunning.
also, within GenerateTreeRecursion, were it recurses you can catch infinite recursions, if either fmax/min or bmax/min are the same as Max/Min, or if the difference of any dimension in any bbox is or very close to 0.0, you also have the general coordanants of the polygons that are causing the infinite recursion, so you can communicate this information back to the user via a message box.
also you can handle this case by making a poly group with more than one polygon in it, most V pofs a bbox encompasses several polys, not always one like PCS pofs tend to.
-
I had to reload the COB and then global data import everything. I'm finally able to get POFS converted in PCS2 to show up ingame, with no problems. Hooray! It'd be nice to be able to drag the model, instead of rotating it. Textures also don't show up; I've tried JPG and PCX, both of which did not render, and I did set the folder they're all located in.
By the way, the list-copy feature is by FAR the most useful thing. Ever. I can turret a model in about 1/10 the time it used to take. Thanks!
If I may, why is there a conversion ratio issue? It seems silly to do anything but 1:1, I'm just curious as to why it started?
-
because the first guy to write a pof converter did it that way, it became standard, all pof editors worked like that and all COBs were made with it in mind.
and you can drag the model, both in terms of actually moving it (hold down ctrl) and in terms of moveing the camera position (hold down shift).
-
anyway, I've been saying for years now that the whole infinite recursion on identical centroids issue can be solved by simply placeing more than one poly in a leaf node, Kazan has always maintained that the POF structure does not suport this, but I know it does from many years of dealing primaraly with V pofs that do just that.
in the pof's bsp structure you have a block of memory and various offsets in this block point to different nodes, typically you have a swarm of sortnorm nodes, each having five offsets in them, each of these offsets points to a diferent node, in practice, the nodes a sortnorm points to will be either a bbox or another sortnorm. bboxes have no offsets, they are simply followed by one OR MORE polygons which are ended by a EOF marker. sort norms exist in this same fashion, theoretically you could have mutable sortnorms as children of another node, and you could put sortnorms inside bboxes. but the V pofs don't do this, and I'm not 100% sure FS would interpret them correctly (I'm at about 95%). but I do see that the polys of the V pofs in these lists are not cocentric, they typicaly have very similar normals, that's about it, but I think this method would be very useful for forever fixing the dredded infinite recursion error.
-
ok, I put my theory to the test, I really really, really really really REALLY _REALLY_ ***REALLY*** would like it if _you_ who ever you are would test this build here (http://freespace.volitionwatch.com/blackwater/pcs2bobBSP.zip) as soon as posable with what ever COBs any verson of PCS has not liked, note I have BSP caching disabled so everytime you save a model it's going to recompile it. also note that is not my sig build and it lacks the dlls that comes with my sig build.
-
ok, I put my theory to the test, I really really, really really really REALY _REAL_ ***REALLY*** would like it if _you_ who ever you are would test this build here (http://freespace.volitionwatch.com/blackwater/pcs2bobBSP.zip) as soon as posable with what ever COBs any verson of PCS has not liked, note I have BSP caching disabled so everytime you save a model it's going to recompile it. do note that is not my sig build and it lacks the dlls that comes with my sig build.
Heh, I don't actually have any SCNs PCS1 doesn't like - whenever it hasn't worked in the past, there's always been a very valid reason for it.
So, looks like I'm gonna have to make some very nasty stuff to try and choke it then? This could be fun. :D
ok, just updated the sig, fixed a few bugs, modified the auto-path (those values seem to work much better) and added an orthographic projection option.
though I'm still working out some bugs with the ortho.
lol, that's awesome. A couple of hours after the request and it's implemented. :D
Anyway, yeah, the autopathing works fine by the looks of it now. Loverly, thanks. :)
A couple of small potential feature requests: (wrong thread sorry, I know, but they're not important ones)
1) Would it be possible to bring back the persistant selected LOD/Debris feature the older builds had? Curently, if you select LOD2 and then go to textures or anything else, it will switch back to LOD0 straight away. However, the new system that highlights the selected subobject is good and shouldn't change back to the 'view-selected-subobject-only' thing. :)
2) Also along this line, would it be possible to view all debris chunks at once?
3) In the texture-editor, a button that would open the currently selected texture (opening it in a particular program, just opening it with whatever explorer has associated with that file type, opening it in a custom PCS2 based viewer; anything as long as it lets you see what the 2d texture looks like) would be really handy. Might that be possible?
4) In the little subobject info box in the subobjects editor, it currently displays only polycounts. Would it be possible to get it to display the stuff modview does as well?
Ie:
Boundingbox min: -32.87|-116.92|1060.50
Boundingbox max: 6.64|-39.14|1079.69
Radius: 38.89
Parent submodel: turret01a
Offset: -13.11|-48.20|1070.09
5) Just a reminder really - for when you're translating subobjects, a text box based co-ordinate field you can edit to set the selected object's offset to. This was planned a long while ago, but just got forgotten about again I think. ;)
and yeah I keep forgetting to put the offset editor in, it'll be a matter of a few minutes, if you had come in a few hours ago I'd have jumped right on it, but I got to sleep now.
-
actualy the offset editor is in, it's just above subobject properties.
and my current code base is testing an experimental feature that has an extremely good chance of not getting into CVS directly, so while I'm testing my little BSP trick I can't realy implement anything else (so try to break that build's BSP converter)
-
Bob, I don't know if it was just added in in that build, or it was added earlier, but using that BSP build you posted in page 14, I was able to properly convert a fighter while only using 3DExploration to generate the .COB.
I am using one of my messiest models when I test all this, so, this might be up to the modeling - but is there something with the smoothing groups? I have one specific area (well, the same area on both sides), where the smoothing groups get a little messed up. Like I said, though, it probably has to do with the conversion/actual model itself.
By the way, a request: when we're fine-tuning the radius, it'd be nice to have a button that makes it visible, a la the F3 viewer in the game itself.
-
1) Yes - bob can you set a toggle button in the taskbar "SubObject select persists" or something - while it's pressed it locks render activity to the current selection even if you select another thing like turrets
2) I'm sure bob could make this mod - "Geometry->LODS" and "Geometry-Debris" as roots
3) this would be sorta operating system dependant... but probably doable
4) i'm sure bob can do this
---
as for "more than one polygon in a single BBox/poly/eof" thing... i'm not comfortable with that... find me a [V] model that does this and get a well defined set of situations..... but as my understanding of BSP trees works that's bad... though i dunno what three of those lists (prelist, postlist, inlist) are for either (and neither did anyone else)
---
smoothing groups are completely irrelevant to POF generation. it's 100% geometry that determines whether the BSP is generated or not.
-
A bug with the renderer: when a toolbox appears if you hover over, say "Render this model as a wireframe", and you move your mouse away, a beige window stays where the toolbox overlapped the render window.
-
actualy the offset editor is in, it's just above subobject properties.
Ah, so it was right under my nose. No wonder I totally missed it. :\
No idea why, but I expected it to appear at the bottom of that editor pane. Ah well, that's great - thanks. :D
-
well that's the way I had it at first, but I thought it was sort of.... hidden there, so I moved it up...
Kaz EVERY V model does this...
for example, (first model I check) bomber08.pof, it has a node with 6 polys in it starting at offset 12100 (thats the bbox, the actual polys start at 12132) in the first subobject. as I look at the data it looks like at least half the geometry is in groups with more than one poly. fighter2s-03.pof has a bunch too, like a group of three starting at offset 9180 (bbox) in subobject 5 (the main LOD object).
-
updating sig with orthographic raypick fixes.
-
I am equally open to shell opening graphics as opening a texture viewer, although I should probably mention that we WILL be implementing a UV editor at some point in the distant future which will basically have the texture displayed. and this will probly be redundent at that point so it might not be worth it to make a specal viewer (shell open would still have some use though, so I think I'm gona go with that one).
what we realy need is a 'reload textures' option, I don't feel like delveing into the texture management code right now though, but a function like that might very well exsist.
I had code specific for reseting the selected model (and thus LOD) to the main LOD root when not in SOBJ editing mode, disableing this code will leave the last selected subobject active. I'll add code such that if the active subobject is debris it will render all debris.
-
I've put the chrash problem on Mantis, alltough I'm stil lnot sure what exactly is causing it..
NOTE - I've put it into the wrong category - PMF Support instead of POF compiler
-
try running it through the build I posted near the bottom of the last page. look in the lower left hand side of the window, in the tool bar, it should tell you what it's doing when it crashes.
hey, Kazan is the path to a given texture saved any ware (and if so, how do I get it)?
-
Wohoo..it managed to convert and save it...
I'll have to test it in-game to make sure it didn't screw up the boundnug boxes or some other stuff....
-
good, I like how that one little thing seems to make the BSP generation bulletproof.... so far...
-
ok, sig has been updated again, fixed a minor issue with the graphics that I doubt anyone will notice, and added most of the requests I got from VA and others.
-
no the path to a texture isn't saved... but it could be with a minor change
[edit]
can you characterize the behavior of WHEN it puts more than one polygon in the same endpoint... is it if all the centroids are within a certain radius?
-
Will you be able to replace the turret submodels on a model with different ones in future builds?
-
PCS2 is no longer alpha - all but 2 features on the 2.0 feature list are complete (those being COB saving and the smoothing reverse engineer that must be done for it) which will be the LAST things put in once everything else is stablized.
New build - please delete your previous pcs2.ini's as there are new defaults that you will need to have
http://ferrium.org/media/pcs2-beta-20070701-1016.zip
the new default is the 1st texture path is <appdir>\textures (<appdir> is a new special-tag that gets replaced by the applications directory) - and included in the zip is a 10x10 transparent .tga for "invisible"
-
hey bob.. how hard would it be for you to setup the code to calculate the MOI of the PCS_File POFTranslated' - since you understand the math better than me. I was just thinking and thought that it would be best to put it in before we move 2.0 to release candidates
(math reference thread http://www.hard-light.net/forums/index.php/topic,39723.msg808065.html)
-
Will you be able to replace the turret submodels on a model with different ones in future builds?
you can do that with current builds, go to the submodel editor and click the load button (ignore save it's on the road to being removed)
can you characterize the behavior of WHEN it puts more than one polygon in the same endpoint... is it if all the centroids are within a certain radius?
when V models do it? there doesn't seem to be much of a rule other than they all fit within a bounding region well (they are all neighbors, they usually, but not always have a very similar normals, there centers tend to have at least one dimension within about a meter of each other). though a lot of the groups, especially those with just two polys in them tend to have a distance of no more than one meter between poly centers.
I could give MOI a shot though I can't promise I'll get it working...
-
I could give MOI a shot though I can't promise I'll get it working...
translated from bob-speak that means "it'll be done in an hour" j/k
go ahead and merge your multiple-polygon code into trunk and tweak compilation as you see fit
-
in all seriousness I've been trying to solve the MOI issue for literally years now, and my calculus skils are now dull and rusty, so eh... might take longer than an hour.
ok, I'll pu it in, but there were a few things about how you were dealing with bounding boxes I wasn't 100% sure about, make sure you look over the bounding box code. worst comes to worse you can always just revert it of course.
-
ok, I'm going to try a per poly cubic aproximation
-
that's kinda what i was thinking
-
Will you be able to replace the turret submodels on a model with different ones in future builds?
you can do that with current builds, go to the submodel editor and click the load button (ignore save it's on the road to being removed)
I select a turret and click load, but the submodel neither replaces the existing turret, nor is it a child of the main hull model.
-
you have to manually delete the turret you don't want (the small button with a red x on it near the top of the submodel editor).
imported subobjects are considered free, go to the tree and drag the imported object onto the object you want it to be a parent of.
-
eeehhhhh ok, screw the MOI for now....
:blah:
man this thing kick's my ass every time...
-
I mentioned a bug in the UI forum, but it should have probably been here, since it was in the most recent test build.
http://www.hard-light.net/forums/index.php/topic,46093.msg973254.html#msg973254 (http://www.hard-light.net/forums/index.php/topic,46093.msg973254.html#msg973254)
-
Another GUI bug, the toolbar doesn't seem to update the buttons on a new file load. For example, I switched to wireframe view, load a new model, it defaults to rendered texture view, but the button for wireframe is still selected. There's probably more buttons that act that way but I didn't think it necessary to test them all.
-
(http://freespace.volitionwatch.com/blackwater/mantis.jpg) (http://ferrium.org/mantis/)
it'll get forgotten if you don't.
-
Right. Guess I'll check to make sure it's not already reported then too.
-
I actually managed to kill PCS2 on the export while stress-testing it. I had an absolutely massive model that was totally unoptimized, and it imported ok (after about a 4-5 minute wait), but after a 4 minute wait on export to POF, it just closes itself with no POF generated, and no error message. I'm emailing you the model, Bob, at the address in your profile.
-
I think it's killing truespace too... I tried to decompose it into subobjects and it's still doing it...
[edit]yeah it's not going to do that is it...
-
I compiled it all into one subobject...I don't have a working copy of TS on this computer ATM, so I would've tried it, but if you really want to see if it's PCS2's fault or the models (I suspect it's that, as PCS2 does seem to be tricky with non TS-generated COBS), you could import the .3DS and save it as a COB.
Otherwise, you can wait a couple days for my computer to get back and I can do it myself :D
-
Request: 1 model with shine maps and glow maps
PS: bob would you know how to render glowpoints?
-
The Loki and Zeus releases are both packaged with shine and glow maps:
http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DLoki/HTL%5FLoki%5F1.0.rar
http://webzoom.freewebs.com/twisted-infinities-va/HTL%2DZeus/HTL%5FZeus1.1.rar
Will they do?
And I'm gonna use my incredible psychic powers to predict that PCS 2 is going to look oh-so-much purdier in a build or so. :D
-
assuming i figure out how to do it
-
i've modified the texture loader to load <texname>-glow and <texname>-shine along with the main texture ... now just to figure out how to actually use them :P
-
Okay, PCS2 just isn't loading for me. I lightly skimmed over this thread and didn't find a solution, so here's the problem:
Whenever I run it, it yells at me about incorrect configuration and tells me to reinstall it :nervous:. It happened with the first, second, this (http://ferrium.org/media/pcs2-beta-20070701-1016.zip) and the one in Bob's signature build. I don't think I should mantis it or not, because I didn't do anything other than extracting and double clicking on the exe, and all of you seem to have it under control.
What did I forget to do?
-
bob posted a msvc8 redist in here somewhere
install this sizz
http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
-
Thank you! :)
-
my sig has a new build, the most obvius feature is obviously a work in progress. to see what I am talking about, you must download it and test it.
-
Oooh, that looks useful. :D
The double-fine resolution is great, as is the way it follows when you move an object perpendicular to that plane.
I know it's a WIP, but just in case:
It's not quite scaling appropriately I don't think. Especially on large ships, it doesn't seem to pick a resolution that's particularly helpful to the positioning of anything. It looks pretty good on small ships though. :)
Might I suggest that it only surrounds the ship itself rather than extending to infinity? I've always found them more useful that way.
Also, found a bug when you try and pan the view around in orthogonal view mode. To mantis!
-
still working on it, I gave up on trying to get it to zoom the scale the closer you got, it just led to flickering hell, zip updated. still working on it though.
-
I'm thinking it would be great if the grid were toggleable. Maybe not through the toolbar, but maybe just the preferences or something. For screenshots and such. Ooh, that gives me another idea. A full-screen hotkey, that makes the render take up the whole screen. Just some thoughts.
-
I was just about to start working on a tool bar toggle button for it.
not sure about the full screen idea.... switching between fullscreen and window can be pretty tricky, and you can make it fill 90% of the screen just by maximizing the window and pulling the control and navigation panels as far as they will go out of the way.
updating the zip, fixed some ray pick issues mostly. I'm prety happy with the grid and, as I just said, I'm going to be hooking it into a toggle now.
-
Dang, I forgot you could pull those like that.
-
PCS2 is great on 16:9 and 16:10 monitors (many "Widescreen" computer monitors are 16:10 like mine - so you can have a 16:9 image on the screen and still have room for controls without occluding the image)
-
grid toggle button in place, build in sig.
-
Bob, using the latest build, that model I sent you now converts, but crashes PCS2 or FS2 on loading.
Just letting you know something changed for the slightly better. :)
Oh...and could that grid be made to scale outwards infinitely?
-
which grid? there are three of them, a small one that only renders +/- 10 'units' (some multiple of 10 meters is scaled to something appropriate for the size of the given model) around the selected item, a medium one that renders roughly within the object's bounding box, and a big one that renders out pretty far.
and keep in mind that the sig build is not an experimental BSP build, so if you used an experimental BSP build last time and this one now, it's a very different beast (don't remember which build you were using, I do recommend trying the experimental BSP though noting any significant differences in the experimental BSP thread).
-
How do you zoom in and out now? It used to be mouse wheel scroll but currently doesn't work. Just stuck with a very too close view of a ship.
How about using dual click for zooming (left and right mouse button)
-
How do you zoom in and out now? It used to be mouse wheel scroll but currently doesn't work. Just stuck with a very too close view of a ship.
How about using dual click for zooming (left and right mouse button)
shift + right button
If that doesn't work - check the hierarchy for groups that don't contain any mesh. This causes the view to be inside the ship.
-
Nope, shift +right button doesn't work.
-
and the scroll wheel doesn't work? try it with a standard model, something very wrong is happening there.
-
Both zoom functions work fine here in both the BSPEX_2 build and standard PCS2. Check that your mouse is over the 3d window while scrolling maybe? Beyond that I don't know. :\
-
if it is happening to an already pofed model - look at the bounding box size. If all zeros then you will need to reconvert from cob or pmf again
If from a cob - hierarchy error is the most likely cause
-
It must be something to do with the model. Other pof's work good. Doesn't matter, i don't need that pof anyways.
-
if the model radius is zero (like the max converter is famous for), that could cause zooming to fail.
-
hmmm... this seems to be a bug, a new one, in pof export, probly related to me trying to fix the huge radus thing
-
ok, I just made a rather important update to my sig, I fixed a bug related to BSP caching, it wasn't saving radius or bounding boxes. you need to open and save any pofs effected by this bug or colision detection won't work at all, and you will be zoomed in and unable to change if you open the file for viewing.
-
This bug here (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/HolySnowballsReturns.jpg) is still happening in this build (and the problem is a lot clearer with the white bounding box being drawn on the selected subobject now :) ), but is fixed in the BSPEX_2 build. Is that a separate issue from what you described above?
-
yes, that got fixed in the experimental BSP, I guess it would be ok to port that bit.
-
ok, fixed now?
-
Yeah almost entirely. :)
The holes are gone now which was the big issue (yay!) but in game I'm still able to fly through it but can't shoot through it. It's kinda odd that it's not both doing one or the other. I would have expected both weaponsfire and ship collisions to be handled in the same way. :\
-
ship-ship collisions are handled very differently from weapon-ship collisions.
as far as I know there are no V models that have submodels that extend far beyond there parent's bounding box (non-rotateing ones anyway)
-
Do rotating ones get special treatment then?
Also, it used to work in PCS1 - that same model was fully collidable all over.
I mean if it shouldn't have been doing that for a valid reason, it's an easy to work with limitation, but it'd be really good if PCS2 either did take non-rotating subobjects size into account for whichever boundingbox collision detection used, of if it let the modder decide how big each one was. :)
-
it looks like there is some special treatment in the FS source, but it's hard to follow. I haven't seen any good explanation as to why it wouldn't be working.
-
Congrats...Using the latest PCS2 I converted the full HTL Typhon... everythnig worked withut a hitch :)
-
it's been requested a few times that I add preset views, I just added a view menu with a few options, have fun.
-
W00t! Almost perfect! :D
lol, I think you might have mixed up left and right with back and front respectively though.
Oh, and for the back and top views, could the model be rotated 180° around the camera's Z axis?
-
Any idea when the new format compatability might start being implemented?
-
W00t! Almost perfect! :D
lol, I think you might have mixed up left and right with back and front respectively though.
Oh, and for the back and top views, could the model be rotated 180° around the camera's Z axis?
it shows that I implemented this in the five minutes before I had to run out for an hour, as soon as I got back I fixed it. I was hopping no one had downloaded in the short time, but it should be fixed and updated already.
UT, do you mean new POF specs? that will be a few months at least, if you mean new import formats (like 3ds) that could happen at any moment.
-
I meant the latter - I know Kazan said he didn't want it, but if .3DS or even .MAX support was implemented, it'd be a godsend for those of us who don't want to go through Truespace. :)
-
Will it also have Compatibility with Wings 3D?
-
I meant the latter - I know Kazan said he didn't want it, but if .3DS or even .MAX support was implemented, it'd be a godsend for those of us who don't want to go through Truespace. :)
.3DS and/or .MAX will not happen. .ASE will happen (Which is supported by 3DS, MAya, Lightwave, etc) - for 2.1
-
Just as an aside, would running the HTL Ravana through PCS2 be likely to clean up its issues (can fly through parts of the ship, can't actually hit some gun turrets) or are its woes due to something in the original model itself?
-
OH - one thing that annoys me to hell with PCS - when converting from POF to COB, it places the center axis (and the glued light) in the very center of the model, instead of the center of the subobject itself.
I can't just convert a Orion to cob, add a turret and convert it back - I have to re-do all the turrets!
Can this be fixed pls?
-
Just as an aside, would running the HTL Ravana through PCS2 be likely to clean up its issues (can fly through parts of the ship, can't actually hit some gun turrets) or are its woes due to something in the original model itself?
open up the POF in PCS2 and go to model info and post what it says in there - i suspect that you used a VERY old version of PCS1 before i fixed the bbox/sortnorm problems that it, and every compiler before it, had
(and... any later version of PCS1 or newer build of PCS2 shouldn't have this problem)
TrashMan: yes
-
This what what the header info for the HTL Ravana look like in PCS2. I do notice all of its subsystems are screwed up, with huge radii.
-
you didn't post an image
and i just need the text from the PINF ("model info")
-
PINF / Model comments is entirely blank.
What I had intended to post:
(http://img.photobucket.com/albums/v106/NelsonAndBronte/FS2/RavanaPCS.jpg)
-
well the header doesn't tell us anything the model comments is were the converter tells us who made it.
and sense it's blank try to just save as pof, it should recompile it.
-
used PCS2 to convert my x-wing today
worked like a dream. great job!
-
To the best of my knowledge the Ravana was a Max pof exporter conversion rather than any version of PCS.
Is it possible to get PCS2 to recalculate stuff like sortnorms/bounding boxes and radii? That could really help the people who have trouble when using the pof exporter, because they could probably fix most of the known issues the exporter has by just recalculating all that in PCS2.
-
well if you open it and then save it, it will probably recalculate it, as from what I've seen the only converters PCS2 trusts would be it'self (current version of it's self) the most recent version of PCS1 and BSPGEN V's pof exporter. note, the experimental build doesn't trust _anything_ and the normal build doesn't trust the experimental build.
-
Indeed, the Ravana was compiled using the 3DS Max exporter, which sometimes produces rock-solid geometry, but sometimes it doesn't.
That's why I've suggested a "regenerate collision data"-button before.
-
well, like I said, you don't need to tell it to, it will, just save as pof and it will redo all the BSP data, if you want to make sure it does erase all model comments, save, open and save again.
-
COB conversion code being written
-
:)
-
PCS2 likes .scn's/.cob's made by itself.. and truespace likes the .cobs - but NOT the .scn's - there are some required chunks for .scn i don't like.. so once i get conversion all a-ok i'll work on that
be advised that when saving to .cob i HAVE to do what PCS1 did and have a root group that owns everything else - it is an ABSOLUTE REQUIREMENT of truespace to have a root chunk (so maybe i should go through and reparent everything to be a child of detail0 ... i think i will do that later)
-
"...go through and reparent everything to be a child of detail0..."
YES.
-
no-can-do
.COB requires the first group specified in the file to be the root group... i can't (sanely) generate the groups in that order unfortunately
which is why i'll have to get .scn working because then we don't have to worry about that :D
-
the cob PCS2 generates should be valid to the point that it can be directly imported back, as long as it produces valid COBs that's fine, but I was under the assumption that the root geometry was the first model and everything had to be a child of that.
-
it does... it's a ***** to generate valid .cob's because .cob's requirements
1) Only one root node (group)
2) root group MUST be first group encountered in file
this is why I want to use .scn - i just have to figure out what the "additional mandatory chunks" are for a scene ('SCEN'... i think 'PHAS' may be mandatory as well, i'll **** with it tilll i get it)
.scn can have multiple roots (each lod is it's own root, each debris has own root, insignia and shields can be root nodes as well)
[edit]
*****ing... something just hit me... i think i just figured out a sane way of getting everything parented to detail0
-
it worked!
[edit]
Build w/ .COB save ability (disabled .scn save.. don't want to fsck with it)
http://ferrium.org/media/pcs2-beta-20070710-1552.zip
-
Wow - it seems to have worked perfectly first time & every time, and it does shields too! :D
I was also very surprised at the constellation of lights the orion had around it, before I realised that they were - path data, engine glows, subsystems, turret firepoints, submodel centres - can PCS2 really autogenerate all that when converting from cob to pof? If so, that's incredible. :D
Great work! :yes:
-
the download link is broken!
-
no it's not... the one two posts up...
-
Hm...this latest build caughs up a win32 exception error and charshes whenever I try to open the the HLT Hecate (captial02t-01.pof .. or something like that).
Also the latest experimental build...
-
i think bob already caught that bug
-
post the model.
I'm about to fall asleep BTW. so it'll be a while before I can get back to you.
-
That's hte Hecate from the vp's (wanted to change the main turret model)..nothing to post...
-
seems to be crashing while saving glow points.
memcpying a class with a string object in it is never a good idea
-
ok, I fixed it, in the sig.
-
ok, glowmapping: working.
yay me.
only took me three freaking /*headache*/ hours to figure out I wasn't setting UV coordanants properly. :doubt:
I got our extension problem solved by using GLee
sig
-
ok, glowmapping: working.
yay me.
only took me three freaking /*headache*/ hours to figure out I wasn't setting UV coordanants properly. :doubt:
I got our extension problem solved by using GLee
After 3 hours you probably don't want to hear this.
Some textures are not loading. Seems to be tga also some dds, but I can't figure a pattern to the missing dds.
The correct texture wire frame colour is showing on the sub-objects with missing texture.
On most of the ones showing texture the texture wireframe colour is black.
The two models I looked at with turrets, only the turrets were missing texture.
Oh and glow maps - ;)
Edit:
The untextured and wireframe views are a lot darker than textured mode.
-
WOW - just got a 20k sub-object into FSO :eek2:
Thanks :nod:
-
(http://img481.imageshack.us/img481/9546/shipzpz7.png)
-
seems to be crashing while saving glow points.
memcpying a class with a string object in it is never a good idea
i had noted that and fixed it.. dunno if i got a chance to commit to CVS repo (i removed POFString::~POFString())
-
well I fixed it and committed it already, so I guess you should be ready for a conflict there.
wait a sec, you removed the destructor!? isn't that going to cause an unimaginably colossal memory leak?
-
(http://img481.imageshack.us/img481/9546/shipzpz7.png)
Not bad, 36 pixel across gives better definition, 24x24 pixel is a real pain for a ship icon.
-
might use those.
anyway, new sig build, shinemapping! hooray for me! I am the greatest! yay!
headache....
anyway, yeah, should be working, test it, be warned it slows things down noticeably.
now I get to go unload 3 trucks for the day!
-
wait a sec, you removed the destructor!? isn't that going to cause an unimaginably colossal memory leak?
the destruction wasn't "Safe" to the way the class was being used - but since that is the only spot where bad behavior cropped up we can go with your usage
-
HTL Hecate still chrashes while trying to open the POF.
The strange thing is that it almost seems random.. first time I tried it chrashes wile loading textures...the second time I tried it chrashed immediately..
EDIT...this is rich...everytime I try it a new error number...
"An unhandeled win32 exception has occured in PCS2.exe [1840]"
"An unhandeled win32 exception has occured in PCS2.exe [3920]"
"An unhandeled win32 exception has occured in PCS2.exe [468]"
etc...
-
were you using my most recent build?
-
htl hecate loads fine for me
-
latest build..tried it now..still does hte same thing...win32 exception (with some random number)
then wants to debug it with Visual Studio 2005...
-
what HTL hecate are you using
-
the pof I extracted from the media VP's...methinks.
-
that's the one that's working fine for me
-
me too.
-
what I don't get is that it works perfectly for other models - HTL Lucy and other ship..
In that case, would anyone send the the .scn or .cob with the HTL Hecate?
-
are you loading it directly from the VP?
-
Nope, I extracted it...that's hte only model I'm havnig problems wiht thus far
-
try loading it directly from the VP. there is a slim posability that you might have a corrupted model.
-
I tried re-extracting it and still the same thing happens..
-
random error codes?
and only on the htl Hecate?
-
made an update to the sig build, it now will auto-extract textures from VP into a temp directory, which you can specify to be any ware you might want (including your mod directory so it will unload them into a place were they will be read by FSO from). it will also load all 3 textures, normal glow and shine.
-
it was already loading all three textures... do you just mean it's actually drawing them now?
-
um bob.. are you ALWAYS extracting the textures to that temp dir? because i consider that undesirable behavior - and tolwyn just reported that it keeps trying to make the temp dir over and over and over
-
it always makes sure the temp directory exists (creates it on startup), but it only extracts a texture when the user wants to open it.
and when I said it will load all three I mean when you hit the external load button it will open all three if they exist.
-
Latest Build has a problem with Textures.Its all white and messed up textures. :ick:
-
post a screen shot.
-
How do I?(Sorry for the noobish asking.)
-
well if you don't have some were to host it you can just use the board's attachment system. you need to use the full 'post reply' screen (not the quick reply at the bottom of the page), under the box you type in you will see "Additional Options..." click on that, you will see a text box titled "Attach" and a browse button, use that to select the file, then post, it'll upload it to a temporary space for forum attachments. it'll be around well long enough for me to see it.
-
I meant were do i find it after i Screen Shoot it?
-
oh, when you hit 'print screen' it will copy what is on your screen to the clip board, you then paste it into an image editor (photoshop, paintshop pro, MS paint if you have nothing else) and then save to file, preferably as a jpg.
-
Here you go-(http://img164.imageshack.us/img164/5761/screwedupcw5.th.jpg) (http://img164.imageshack.us/my.php?image=screwedupcw5.jpg)
-
wxMKdir throws a error window if it tries to create a dir that exists... soi added in a checkfor direxists
-
hmm... can't believe that didn't cause a problem for me before I released.
anyway, Hades, what version is your Open GL?
-
made a minor update to the sig, it now has some compatibility checks for multi-texturing, and I added an OGL info menu item in the options menu, it will produce a message telling you all sorts of info about your OGL setup, and it will paste it to the clipboard so you can paste it into forums if such a situation should ever prove useful to you.
and is anyone getting an issue like hade has, that's something I'm on a major lookout for.
-
we're getting pretty close to RC builds here.. only one feature left for me to implement... can you ad an "About" box with appropriate info
-
and is anyone getting an issue like hade has, that's something I'm on a major lookout for.
Well.. I'm finding the glow map onward builds less fun.
Current builds locking up machine sometimes loading otherwise when saving. Reset button material. Crash to desktop would be nicer.
No tga's being displayed. Some dds not being displayed. All worked previously.
Subset of the city (one of each building) pof will crash FSO.
One crash was while writing shield collision tree.
-
kazan reimplemented some sort of modal dialog thing, and I've noticed there seem to be a few what I believe to be race conditions since then (I'm guessing this is what it is, cause they are extremely random). I was thinking he was still working on that, and I've kept myself busy with things, and I didn't have much information to give on them, so I hadn't said anything, but I know there were a few access violations on things, I've tried adding some conditionals or initial values around them as I find them.
-
be race conditions since then (I'm guessing this is what it is, cause they are extremely random).
The lockup randomness delayed the report, couldn't pin it down. The CTD while writing shield collision tree is repeatable though.
-
give me a model that CTDs SLDC so i can find the cause
-
I'd be interested in that model too, in case something is happening in the bsp function.
-
it's probably in PackTreeinSLDC not MakeTree
-
hmm... can't believe that didn't cause a problem for me before I released.
anyway, Hades, what version is your Open GL?
It's not my Open GL, Becasue it didn't do it the last versions.I even have the textures in the maps folder.They look normal in game, but not in PCS2.
-
it didn't do it in previous versions because shine and glow weren't implemented - which is using higher demanding openGL features
-
Oh, were can i find the latest OpenGL Update?
-
they're part of your video card drivers, what video card are you using
-
Hmm i don't know, but i know it is 58 MB.
-
58? that is a very odd number...
there is an option in the options menu, it will provide information about your openGL setup, please post what it tells you here.
-
OpenGL Version is "1.4.0 - Build 4.14.10.4543"
Vender is "Intel"
Renderer is "Intel 945GM"
There you go.
-
ok, thanks, that is interesting.
-
ok, I couldn't find any obvius incompatabilities, so I doted the section of code with a number of error checks, my sig has been updated, run it, if you get any error message be sure to tell me what it was, and what line it was on.
-
and hades, if you have not done so yet, update your drivers (http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2301)
-
ok, I couldn't find any obvius incompatabilities, so I doted the section of code with a number of error checks, my sig has been updated, run it, if you get any error message be sure to tell me what it was, and what line it was on.
This will crash pcs2 20k moon (http://homepages.paradise.net.nz/pcantwel/dl/20k.7z)
Its a 20k poly test object but PCS2 has managed to convert it before.
Processing Objects (0/1) [Smooth
-
Ok now i can't even load a None HTL chary. :ick: :ick: :mad2:
-
now is it crashing or just seemingly not doing anything for a very very long time? cause the way we have our geometry set up currently auto-facet smoothing is an n^2 operation, though I did a bit of work today on a universal geometry format that should be able to do things like that a **** ton faster.
[edit]took 7 minutes but it loaded.[/edit]
-
now is it crashing or just seemingly not doing anything for a very very long time? cause the way we have our geometry set up currently auto-facet smoothing is an n^2 operation, though I did a bit of work today on a universal geometry format that should be able to do things like that a **** ton faster.
[edit]took 7 minutes but it loaded.[/edit]
Most of the time it fails with a standard application failure dialog box.
As long as its using the cpu at 60 -100% I don't mind waiting for it to finish. I'm sorta used to it taking its time on some conversions.
-
ok, lets try this a different way.
http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_11__21_28_45.zip
does this build have the problems? it's reverted to july 11th late night.
-
Yes it works. :yes: :yes: Good job.Thanks. :lol:
-
ok, so it was something that happened after 9:30pm wed...
-
go into pcs_pmf_pof.cpp and find "SLDC" in SaveToPOF and comment it out
-
they were having problems loading from cob, not saving to pof
anyway, try this one
http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_12__12_25_14.zip
-
they were having problems loading from cob, not saving to pof
anyway, try this one
http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_12__12_25_14.zip
Hmm doesn't work. :doubt:
-
Of these last two builds, the first one has no problems for me, but the second one has the white overlay problem described in mantis bug http://ferrium.org/mantis/view.php?id=32
Unlike the latest sig build though, the second one doesn't crash outright when loading any POF.
OGL Thingie:
OpenGL Version is "2.0.1"
Vender is "NVIDIA Corporation"
Renderer is "GeForce 7900 GT/PCI/SSE2/3DNOW!"
-
Originally I thought some textures weren't being displayed, but on closeup look the textures were there faint with a blue/grey cast
(http://homepages.paradise.net.nz/pcantwel/images/messed-up.jpg)
3 models tested - except where it crashed on model 2
July15 00:34:30 ----- (1) textures messed up - (2+3) load and save ok
July15 00:07:45 ----- (1) textures ok - (2+3) load and save ok
July14 18:02:02 ----- (1+2) application crash on load
July14 06:57:26 ----- (1) textures messed up - (2) App crash writing shield collision tree
July13 06:19:53 ----- (1) textures messed up - (2) Full lockup on model load - machine reset.
-
ok, I guess hades is talking about the render bug, not the 'crash for no apparent reason' bug.
ok, lets see if the render bug is related to glowmapping or shine mapping,
if you have the render bug with this one, then it's a glow mapping bug, if you don't it's a shine mapping bug.
http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_12__8_34_21.zip
it should not have the crash bug in it, but if it does, tell me.
-
Yep, render bug is present with that one.
As I said in the mantis bug, it looks like it's just rendering a white overlay over the tops of textures that don't have their own glowmap, and then it renders one of the other maps glowmap over the top of this white overlay.
-
Load and save ok
Texture problem became very clear on that one.
The orange in the previous pic became very white. In another model the dark textures still show up but the lighter textures disappear (to white)
-
For multi-part turret autogen - should PCS2 add the firing point and normal, or do you need to do that part yourself?
-
create lights named TurretNN-FpUU
Where TurretNN is the 01, 02, etc - UU is unused - it assigns Firepoint # in order it's found
position the lights where you want the firepoints to be, and glue them to the TurretNN-arms subobject. the light positions with be the fp positions - the normal will be the vector between the geometry center of TurretNN-arms and the average position of the firepoints
ie if the geometric center of the object is 0,0,0 fp 1 is at 1,0,0.5 fp2 is at 1,0,-0.5 then normal will be normalize((1,0,0.5+1,0,-0.5)/2-0,0,0) = 1,0,0
(normalize takes a vector and makes it magnitude 1)
-
ok, I doubt this is the problem, but just maybe it is, test this (http://freespace.volitionwatch.com/blackwater/pcs2_glow_fix_maybe.zip), see if it works now.
-
why dont you just run the debugger with one of the models that breaks?
-
cause it doesn't break for me. I tried it already.
and that last build I posted was to see if I figured out why glow maps were ****ing everything up.
-
aaah
-
Works perfectly at my end. :D
All properly gloweymapped and no white textures at all now. :)
(Assuming shine maps were still disabled in this build for glowmap testing purposes?)
-
/*smack's head*/
I can't believe that was it... I'm such a dumbass... wait, why the hell did it work for me?!
that seriously should have either worked or thrown an invalid enum error!
...updating my sig, still haven't identified the crash bug, so it's probably still in there.
but if this fixed that it would just freaking figure.
-
don't you love bugs like that :D
-
ooooh, so much!
-
Having a problem with this, using a "your sig" version from July 15th 12:26:56. Quite possibly due to ineptitude on my part though - I started modelling... two days ago :p So I'm not exactly expert in POF conversion. But anyway, in case it's not:
The model causing the problem is a container (essentially a glorified box with lots of greebles that's modeled on something I saw on the BSG show, with only one LOD so far - Want to make sure it can convert before I start UV mapping the other 3), and the .cob seems to load just fine into PCS2 and renders fine as well. However, when I try to save it as a .pof the status bar gets as far as "writing shield collision tree" (it's a container, no shields), then crashes.
Sooo... help! Or not, in case it's me being stupid and needing to do something before I save as .pof, or for that matter me having done something wrong with the actual model in the first place, in which case, feel free to yell at me. Attaching the model (in .cob format) so you can see for yourself whether I'm just being ignorant or not.
PS. Yes, I know it has insanely many polys for a container, even for LOD0. I'm not feeling confident enough modelling to try on detail boxes yet, but it will come eventually :)
[Edit] Actually, I think TS did something weird to the model. I just loaded it up again and it had 4x the faces it should have. Lemme try a backup, it might well be a problem on my end.
[Edit again] Never mind, it's apparently just a side effect of UV mapping. The thing comes out of LU with my faces than it has going in. Probably me forgetting to check some box somewhere. Just to be sure though, I'm also attaching a version that hasn't been through LithUnwrap. Still crashes PCS2 but you might be able to find out more than me.
[And again] Tried some workarounds. Using cob2pof, I can convert the model and see it in modelview. However, neither PCS or PCS2 will accept a .pof made that way - PCS refuses to load it and asks if I'm sure it's a valid FS2 model, and PCS2 will load it but does not render it even as a wireframe, with all values (bounding box, mass, radius etc.) shown at zero. Trying PCS on the .cob, it hangs and takes up a ton of cpu cycles.
[Attachments deleted now since the models were not to blame]
-
...updating my sig, still haven't identified the crash bug, so it's probably still in there.
but if this fixed that it would just freaking figure.
lol, yeah the crash-on-load bug has vanished from your latest sig build now too. :D
-
excellent and i have a model to track down the SLDC problem.. oh **** i bet i know what it is :D just occured to me :D
-
Having a problem with this, using a "your sig" version from July 15th 12:26:56.
Yes the writing shield collision tree crash is present in this build. Also fails with ground-scale.cob.
Shade use this one as a temporary measure http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_11__21_28_45.zip (http://freespace.volitionwatch.com/blackwater/pcs2_2007_07_11__21_28_45.zip) It will do what you need.
-
And here I thought I was being clever downloading the build from the sig instead of one of the posts, figuring it was the most up to date. The one you just linked me converted the model flawlessly :) Thanks! I still gotta figure out the poly bloat from UV mapping though, but at least, this is one worry less.
-
someone with a model that is crashing on SLDC.... put a shield box around it and try again.. i bet you the crash will go away
-
something along the lines of making a collision tree for a shield mesh that doesn't exist I'm betting.
and the one in my sig is the most up to date, it's got bugs in it that other build couldn't even think of.
-
the one in my sig is the most up to date, it's got bugs in it that other build couldn't even think of.
what did you do...
-
I was being sarcastic, but for example, that one build doesn't have any shield collision tree code, so it couldn't even think of a bug in that code, get it? t'was a joke. considering we posted at about the exact same time and I was responding to the post before yours.
anyhoo, anyone who has had problems over the last few days, please make a report on how things are working for you now. note we still have the above mentioned bug in the wild regarding shield collision trees, so we know about that one, but make sure you don't have any glowmap/shinemap crash after loading bugs.
-
Interestingly, I just realized that PCS2 actually undid the poly bloat from the UV mapping during the conversion process. This is good. Just need to fix up a table now and this thing should be working. I thank thee :)
-
undid the ploy bloat?
-
Well, strictly speaking, vertex bloat, I phrased it wrong before. I take it you downloaded the models? The UV mapped, non-converted model has 5k-some vertices, the un-UV mapped one has 1600ish. But after going through PCS2, the UV mapped model is back down to 1600ish. I don't know why, but then, I am rather new at this. I just know it's nice, because it had me worrying and trying to figure out wtf was going on. Which, apparently, nothing was :)
-
oh, yeah, it merges identical vertexes.
-
And because of PCS2, I was eventually able to get it in game! Yay :) It's a nice feeling seeing something of your own in the techroom for the first time. Now I just gotta actually draw stuff on the texture... plain maroon is kinda bland :p Oh, and LODs. Might as well do it right.
[attachment deleted by admin]
-
someone with a model that is crashing on SLDC.... put a shield box around it and try again.. i bet you the crash will go away
So how do you do that? I'm guessing a mesh made in a modeling program. With the name shield? or is there more to it than that?
-
just like any other subobject.. just named "Shield"
-
As you said, with shield - no crash
-
kk think i have it fixed then.. commiting to CVS.. checkout bob's next build
-
Well, strictly speaking, vertex bloat, I phrased it wrong before. I take it you downloaded the models? The UV mapped, non-converted model has 5k-some vertices, the un-UV mapped one has 1600ish. But after going through PCS2, the UV mapped model is back down to 1600ish. I don't know why, but then, I am rather new at this. I just know it's nice, because it had me worrying and trying to figure out wtf was going on. Which, apparently, nothing was :)
Here is why you have 4188 extra verticies in your model.
Each triangle face has 3 verticies ------ A cube with 6 faces = 12 triangles
With all the triangles JOINED together in a cube = 8 vertices (1 vertex per corner - shared with several faces)
With the triangles NOT joined together = 12 faces x 3 vertex per face = 36 verticies (4 or 5 vertex per corner)
-
damn HTL Hecate still won't open..
Can somoene send me the .cob of it pls?
-
I don't suppose you have VS2005?
if you could run it through the debugger on your system it would tell us were the bug was.
-
Unhandled exception at 0x10007657 in pcs2.exe: 0xC0000094: Integer division by zero.
IF I CLICK CONTINUE:
Unhandled exception at 0x10007657 in pcs2.exe: 0xC0000094: Integer division by zero.
IF I CLICK BREAK:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
-
don't click continue.. find the line in PCS2 that it occurs at
-
oh, divide by zero,
but I meant actually compile a debug build and run it. I'll zip up my local code base and upload it for you.
http://freespace.volitionwatch.com/blackwater/pcs2_source.zip
although now that I think about it, there are a bunch of other dependencies (wxWidgets, DevIL).
better idea, I'll upload a debug build, it should produce the name of the function causing the problem if you hit the debug button when it crashes.
http://freespace.volitionwatch.com/blackwater/pcs2d.zip
-
Debug build fails to start at all..
"This application failed to start becoause hte application configuration is inccorect. Reinstalling the application might fix the problem."
You know what - forget it...I'm not gonna touch the HTL Hecate :blah:
-
ah ha! you don't have the mscv 8 redistributables... link is in the PCS2 wiki page
(well you do.. but not a fully up to date version i bet)
-
come on, we need to get this bug fixed, it's only going to bite us in the ass if we leave it.
I just noticed, you never actual answered my question, do you have VS2005? sence you were talking about stack frames an source code I figured you did, but if you don't have those dlls, then maybe not.
-
Ya, I have MVS 2005...don't recall when I installed it tough..probably the same time I installed SQL server 2005...
I'm gonna DL those files and try again..
EDIT - still nothing..
-
ok, I just tried packing all of PCS's external dependencies into a zip, and it came out to be more than 40mb, if I upload that would you be willing to download it and the source compile it on your end and try to run it in debug? if you compile it I garentee it'll run.
and kazan I just noticed a bug with our BSP compiler, think about what would happen if a polygon landed exactly on the split between two bboxes. like you might get if you converted a cube and it split it in half, you'd have 4 polys that were on the split plane.
another clue our bbox functions use point<=min && point>=max.
if you still aren't seeing it, in this unusual but easy to reproduce situation, there will be polys that are consitered to be on both halfs of a split, or in both child bboxes, the way our code works this will result in duplicate polygons.
-
and what is wit the uninitialized head node in PackTreeInSLDC? shouldn't that be split not head, head isn't initialized, and you are using split every were else in there.
I think I figured out a fix for the problem mentioned above, unfortunately it has an extremely slim opening for infinite loops, but I can not think of a situation were it could ever actually happen, I'll be committing it shortly.
-
I hope we can get 1.0 rolled out soon I have a neat little geometry class I want to use in place of all our kaz_vector<pcs_polygon>s, it'll make auto-facet calculations ridiculously fast, and will enable us to make vertex/index buffer sets realy quick too.
-
you mean 2.0 :P
but yeah i just need to write the code to reverse engineer smooth v faceted v autofaceted and the autofacet angles of a kaz_vector<pcs_polygon>
-
Hey Guess what? PCS2 can't open Hecate but it can open HTL Lucy. :lol:
-
so you can't open the Hecate either?
-
Hey Guess what? PCS2 can't open Hecate but it can open HTL Lucy. :lol:
My version opens fine from vp with textures, But what vp file/version is yours from?
-
so you can't open the Hecate either?
I just tested with the Hecate from the media_vp and the build from your sig, it CTDs every time I try to open it.
EDIT: The same thing happens with cruiser01 and cruiser01x, the HTL Fenris and Leviathan.
EDIT2: And corvette2t-01 (Deimos?)
-
AHA! So now we have a bigger problem on my hands...and you don't need me anyore for testing now that you have other....guinea pigs ;7
-
position the lights where you want the firepoints to be, and glue them to the TurretNN-arms subobject. the light positions with be the fp positions - the normal will be the vector between the geometry center of TurretNN-arms and the average position of the firepoints
ie if the geometric center of the object is 0,0,0 fp 1 is at 1,0,0.5 fp2 is at 1,0,-0.5 then normal will be normalize((1,0,0.5+1,0,-0.5)/2-0,0,0) = 1,0,0
(normalize takes a vector and makes it magnitude 1)
Thanks
I think I set everything up right though I found that the firepoint worked when it was under turret01-base group rather than arms.
also the normalize button didn't do it's job
-
so at what point exactly does it crash? what part of the model is it loading?
-
so at what point exactly does it crash? what part of the model is it loading?
Aha, excellent question. The last thing I read is "loading textures" and the name displayed on the lower left besides the progress bar is "nameplate".
On closer inspection I see that it's hanging on the nameplate on all of the models mentioned above. So it might be something about the default nameplate texture (which is fully transparent IIRC ?) or maybe it doesn't find it in the VP.
-
devil has no problem with transparency etc.... bob and you still linking to a different version of devil from me?
it's time to renable texture debug
-
ok, I'm going to add a bunch of message boxes to the signal new model function, so if it is crashing there, it will narrow it to a few lines
http://freespace.volitionwatch.com/blackwater/pcs2_testing.zip
-
Heh heh.It is like it is talking to me. ;) :lol:
EDIT:SHINE MAPS> :D
-
ok, were does it stop talking, what is the last thing it says?
-
ok, were does it stop talking, what is the last thing it says?
"so, the model is fine, so maybe it's in the textures ?"
When the crash message pops up, PCS2 is still open and I see some untextured geometry in the render canvas.
-
Ok, I removed the message boxes I had and added a ****ton into the texture loading functions, do the same thing, keep in mind there are a LOT of them this time. tell me the last thing it says before it dies, this will locate the crash to withing a few lines or a function.
-
Everything goes fine until we hit the nameplate texture:
Then I get:
found a texture -> click OK
it's name is: 'FS2path\data\maps\nameplate.dds' -> click OK
-> crash: "pcs2_testing.exe has encountered a problem and needs to close. We are sorry for the inconvenience."
-
that would tell me something about the nameplate.dds is crashing the DevIL library
-
Gah, the board ate my post. :\
Anyway, yeah I encountered this bug much earlier in this thread. Fixed it by replacing the tiny 4x4 nameplate texture with some test texture. It's not an efficient one, but that fixed it.
I've attached a zip with both the broken nameplate texture and the working one I'm using. Bob/Kaz you might want to take a look at the borked one to see if it's a problem with the image file itself or if there's something about it (too tiny maybe?) that DevIL doesn't like. :)
[attachment deleted by admin]
-
bingo! I just managed to reproduce the crash, I had a different nameplate texture.
-
I just managed to find a model-corrupting-bug in the glowpoint handling code - specifically corruption being introduced in the properties
[edit]
bob! you forgot to cvs add new files! (geometry.h and others)
-
eh... were was that, that shouldn't be there...
in main_panel erase the include for geometry.h and the block of code testing it in the bottom of SignalModelChange (it should be commented out anyway), I had not intended to commit that.
or, don't I'm probly going to commit in a few minutes.
-
ok, sig updated and fix committed, test it out, nameplate.dds should simply fail, rather than crashing the program.
-
PS: the corruption problem is in POF adding glow points - during array copy the POF String's for properties become corrupt
-
so I'm assuming it worked?
-
no i just knew where the bug was already gotta find out why... you know that you have a cast error in tex_ctrl.cpp at line 157
[edit]
bug was already fixed by up to date builds apparently
-
I'm not sure if this is a bug or not, if it is I'll mantis it but I suspect it's just something funny in a cob. I rendered this platform in Truespace, and the hangar appears open, as well as when I imported it into 3DS Max after saving it as a DXF. I did have to use the Unify Normals option for it to appear normal in max, but that's probably not important. What happened after importing the cob into PCS2 though, is that it seals off the hangars with polygons that don't appear in truespace. Any ideas?
[attachment deleted by admin]
-
I don't suppose you could give me that COB?
it might be my geometry filter if there is some weird geometry there.
-
you answered your own question
-
PM sent.
-
ok, I got it, it does have some odd geometry, got a bunch of holes, I'm thinking conversion to cob did this mostly though. I turned the geometry filter off and it seemed to get worse, unfortunately I just ran out of time so I can't work on this right away, but the geometry filter should be correcting these issues (if they are what I think they are) I'll have to work on it later tonight after I get back from my meeting.
-
he probably has convex polygons.. convex polygons are not allowed
-
he does, en mass, but that is exactly what the geometry filter is suposed to fix, and it's not, this is very good for me, cause it means I've got something to work on tonight, but I wonder what's going on there, I think it's more than just convex polygons.
-
how exactly do you make convex polygons out of concave ones...
-
simple, you find the convex points, that would be the ones who's internal angle (angle measured from the inside) would be more than 180, you can find them easily enough by taking the relative crossproduct of the two neighboring points and doting it with the poly's normal, anything <= 0.0 is a convex point, if you have more than one then you divide the polygon into two separate polygons by connecting the first and second convex point, as a fall back you start trying to make good polygons starting at the furthest point from the convex one, you test every poly you make to ensure it is not convex it'self and eventually you will find a way of splitting the polygon that will not result any convex polys. or at least that's what I reckon. I did act for people to try and find a way to break the geometry filter when I was making it, someone finally did. :) (maybe)
ah, I see, my method fails if two convex points are right next to each other
-
Well if it did, I guess I'm glad, but I can't take credit for the model, it was a former SWC member who left it to us to texture.
-
I think I just figured out a better algorithm, once you find a convex point, you reverse directions and look for the first point that will result in a convex point if split between it and the convex point you found split between the identified convect point and the one before the one that will cause a bad split, then recurse the remaining half of the polygon.
-
hey bob... here is what i was thinking for the smoothing-reverse-engineer
it runs on a vector of pcs_polygons
iterate over all polygons
for each polygon
(return when condition met)
1st) check all points to see if they're faceted
2nd) check all points to see if they're full smooth
3rd) iterate over all points, find their neighbors, determine minimum and maximum smoothing angles which result
in the correct resultant
find the minimum angle valid for all points
sound good for you?
-
sounds like it should work, though I think there will probably be a lot of situations where it will produce a blob of full smooth with a bunch of different auto-faceted bits on the perimeter. it would probly be a good idea to allow the user some options, such as simply providing a global auto-facet angle if they know it only used one
-
how would it do that? it's on a per-polygon basis
oh and we have a problem in the compiler... setting normnum to -1 (which means the norm wasn't found)... this shouldn't be possible...
-
well like I said, GLOBAL, if the user doesn't want to sit and wait for eternity for this to calculate they should have the option of using a less accurate method, such as just providing an angle to use on all polygons.
norm -1, I would bet rounding error is responsible for this, in stead of using vector==vector, you should use dot(vector,vector)>0.99f or something similar.
I have a geometry class in the works that is built around making a lot of these comparisons faster, it has a single list of points which is referenced by a list of verts which are used by a list of polygons, every point keeps a reference to every vertex which uses it, and every vertex keeps a reference to every polygon that uses it, it makes looking up stuff like neighbors extremely fast. it'l be (nearly) an N*logN operation rather than (worse than) N^2, because the largest chunck of data (points) will work on a ordered index, and you can use binary search on that. (keeping everything in order is the major coding problem of this method, especially given the interdependencies, but it's the only way to avoid an unacceptably long processing time). I have it set up so it can keep everything up to date all the time (this mode is mostly for geometry editing) or allow you to make a few changes and then fix it later.
-
A.A should equal |A|*|A| not 1
A dot B = AxBx + AyBy + AzBz
but that would probably work.. problem is it would also produe false positives i think
-
well sence the normals are by definition suposed to be unit length, then it means the only variable involved is the angle between them, which should be close to 0 if they are about the same. and cos(0) == 1
as long as the test angle is less than what can be easily perceived then it shouldn't matter if it's a false positive.
-
you're thinking A dot B = |A||B|cos(theta)
plus i would be altering operator==(vector3d, vector3d) so it needs to work for more than just norms
-
well, normals are used in very diferent contexts than most vectors, even though they are the same data type. I don't think you can make a universal solution for this, unless you make a vector3d derived class for normals.
-
ok folks new build in my sig, undo/redo functionality should be working.
please test and report any problems here and more importantly in mantis.
-
awesomeness
-
wow nobody has looked at this all day have they?
undo/redo!
sig!
now!
-
it's been quiet lately
-
I can now open the Hecate. :yes: There seems to be no bugs sofar.
-
is anyone working on *.ase yet?
-
read the roadmap - .ase is 2.1
-
yeah we are planning our first full release version very soon so if we can get a surge of testing for maybe a week or two we might be able to start on stuff like that.
kazan only has one more feature he want's implemented before then and this pretty much completes my list.
-
fixed a bug with right click omnipoint moving, it was broken and nobody else noticed this till just now, I guess I'm the only person who uses it.
-
I only just saw this now, oh impatient one. :p
I was also just about to report that omnipoint movement bug and a bug with the grid crashing as soon as you rotate. ;)
Anyway, the undo/redo seems to be working great for me thus far, but I've been testing it for all of 2 minutes.
-
Will the new format import be in the full release version?
-
no, work on new file formats will begin immediately after the full release.
-
Crikey - is there no limit to the number of undo/redos? I just managed to undo and then redo 100 movements of a point, stopping there only cos my finger was getting tired. ;)
Also, it seemed to erase the undo/redo data as soon as I clicked a different chunk (ie, thruster points having just edited gunpoints) and then went back. Is that supposed to happen, or is it supposed to be a different set of undo/redo data for each chunk, or is it supposed to be a global action undo/redo type thing?
-
it's chunk specific, there is no (hard) limit to the number of undos/redos, though it probably will start to consume memory if they get too long (especially subobjects which I'm probably going to have to treat specaly). I was considering making them survive past chunk selection, but I figured if you are moving to another chunk you are probably pretty happy with what you have, so it seemed like a good time to free the memory logging all those changes used up, and it just so happened that this was exactly the behavior my implementation got, I could make it persistent without too much pain if that would work better, but it will still be related to the current chunk, sort of how in a MDI word processor if you hit ctrl-z it will undo the currently selected document even if you just selected it after doing all sorts of stuff with something else.
-
ok, fixed the grid bug I think.
-
Insignias...we need insignia support back..the old PCS would automaticly set insignias if you had planes as a subobject named InsigLOD000 and so on...
-
Grid bug is gone, yep, and as far as I've been able to determine, the undo/redo seems to work for everything it should. :)
(I still need to do some more testing there though)
I could make it persistent without too much pain if that would work better, but it will still be related to the current chunk
Yeah that'd be great I reckon, since it allows for the most flexability.
It might need a way to be able to clear all that data though if it's beginning to get to the point of slowing the system down though. How would you handle that?
-
Insignias...we need insignia support back..the old PCS would automaticly set insignias if you had planes as a subobject named InsigLOD000 and so on...
the current one should be too...
-
it will auto-gen insigs, there is just no interface, I had planed on having a interface for insignias were you would have a bunch of boxes and it would make them out of were the box intersected the hull, but that was suposed to be a next stage feature, I suppose I could make a viewer editor like I do for shields.
-
I guess no one is finding any bugs?
we should probably start making RC builds soon.
-
yeah i just need to stop being lazy and write that bit of code
-
I guess no one is finding any bugs?
we should probably start making RC builds soon.
Don't know if you consider it a bug.
You can be in xy constrain mode - with x and y locked and the only axis you can move is the z with right mouse
-
well, not realy, if you lock both axies then you shouldn't be able to move on either of them, if you find you get confused with axis locking then just don't use it.
-
i just realized a serious problem with the interface... how do you zoom without a scroll wheel
-
Shift+right click already takes care of that. :)
-
well, not realy, if you lock both axies then you shouldn't be able to move on either of them, if you find you get confused with axis locking then just don't use it.
Heh - nice one
Of the many users for PCS2, some will be very proficient in 3d and some not.
The constraints and locks force the user to think boolian.
Say I want to move in just Y
so you pick XY or XZ and then you have to pick NOT Y (X)
People only use the locks for one thing - to constrain to a single axis.
From a UI point of view - make it easy
Constrain to XY , XZ, YZ
Constrain to single axis X, Y, Z
So instead of 12 button combinations you end up with just 6, and with just a single click
(http://homepages.paradise.net.nz/pcantwel/images/icons4.gif)
-
the axis lock setup is based on truespace's UI, and this is how it works there. the idea is if you are in a constrained mode and you find you just want one you turn off the other axis, if you want to make sure you don't accidentally move in anything but one you turn off the other two. if you want to move in just one direction you can always just use the right button movement. so there are several different ways to get what you want, some times locking an axis feels better sometimes using a different constraint works better for you.
and you need to update your mantis bug report.
-
the axis lock setup is based on truespace's UI, and this is how it works there. the idea is if you are in a constrained mode and you find you just want one you turn off the other axis, if you want to make sure you don't accidentally move in anything but one you turn off the other two. if you want to move in just one direction you can always just use the right button movement. so there are several different ways to get what you want, some times locking an axis feels better sometimes using a different constraint works better for you.
From a UI point of view it's not a good choice. How long is the projected lifespan of PCS2? with how many users in that time
From my point of view to move something now in the Z axis - I will choose the constrain that does NOT contain Z (XY) and use the right mouse button. (Not Intuitive)
The example earlier where you thought I was confused because I ended up with X and Y locked, happened because
Locked X while in XZ mode
Locked Y while in YZ mode
When I switched back to XY mode both were locked
After a week of using PCS2 (not testing) the lack of hot keys for the views + ortho + constrains really slows things up.
suggest
1-6 front, side etc
7 ortho
8, 9, 0 constrains
User assignable hot keys would allow people to set it like their favorite modeling app. This would be really appreciated. I know Truespace 3.2 is a button clickers paradise, but it is also one of the most clunky interfaces around.
There are other points that could be raised about the UI, but they would require pictures to show. For a coder this stuff is probably really dull compared to the more challenging stuff in the back end. Unfortunately for a user the front end is the application - the magic you have put in behind the scenes becomes invisible due to it hiding the complexity and getting the job done.
and you need to update your mantis bug report.
Ah.. just found the notes link.
-
I can add hotkeys to views'n such.
-
From a UI point of view - make it easy
Constrain to XY , XZ, YZ
Constrain to single axis X, Y, Z
So instead of 12 button combinations you end up with just 6, and with just a single click
I really like Waters idea (and axis constraint icons) here. That'd be a great way to handle it I reckon. :)
And yeah, hotkeys would be a great help for the veiws and the like.
In fact, might I suggest they be handled like blender does with the numpad? I've always found it to be the best key-controled viewer I've used in terms of accurate positioning of the camera. It's a very fast way to get precise control.
The numpad arrows 2, 8, 4 and 6 control rotation by set incriments (15° or so) rotating towards the down, up, left and right respectively (Much like those interface buttons in early PCS2 builds did).
The keys 1, 3 and 7 snap the view to the presets of front, left and top respectively. Holding ctrl and hitting those same buttons will get the back, right and bottom views, and finally the 5 key toggles between orthogonal and perspective mode.
-
Nice...I finalyl managed ot conver the HTL Hecate to .cob...now to work my magic on it :D
EDIT - You planing on using my Athena icons? Or would you prefer some other ship (Hercules, Persus?)
-
Ok here is another way to handle the lock problem without much work.
Use these icons for constrains - The red indicates single axis right button mouse mode.
(http://homepages.paradise.net.nz/pcantwel/images/icons5.gif)
With a Help > mouse+keyboard page showing the blue/green as left mouse and red for right mouse - would make the three lock buttons redundant.
The only other graphical UI stuff would be to have both the grid and standard model wireframe colour included in the options colour settings. Eg Diffuse + Ambient + wireframe + grid
The ability to change the background colour would take care of models with very dark textures.
And yes I'd love to have hot keys (settable or not) They would be a huge productivity boost
Model reload
(http://homepages.paradise.net.nz/pcantwel/images/icons6.gif)
-
oh bob... File->Save and the Save hotbar button should save to the already open file, save as should be required for format changes.
(and if saving to COB we should warn about not all data can be saved)
-
Quote from detail box page
keep in mind that detail boxes are in the subobject's frame of reference, so any rotating submodels will have rotating detail boxes (this can be worked around by making them children of polyless subobjects with a detail box).
My question is how do you make(import) something as child of a polyless subobject in PCS2.
PCS2 has a habit of dumping any branch on import that doesn't have a mesh (even if it has a child group with a mesh.)
-
Warning, I have dozens of models that PCS2 (both kazan's and Bob's builds) cannot show onscreen even when pointed to that model's folder in preferences. Textures are both in .bmp and pcx format with the .cob.
Also model will NOT show in solid or wireframe mode...
I'm posting just one of these models inteh hopes you can tell me what is it about them that makes them invisible in PCS2...
Thanks!
http://upload2.net/page/download/5QIODIVa9c3wKby/yamato.rar.html
Incidently are models required by default to have a shield mesh? (even caps?) because I figured I would make the pof and then later edit it with model view to replace the textures to see it HOWEVER PCS2 fails on "writing shield collision"...
-
Incidently are models required by default to have a shield mesh? (even caps?) because I figured I would make the pof and then later edit it with model view to replace the textures to see it HOWEVER PCS2 fails on "writing shield collision"...
Shield collision has been fixed - download Bobboau's latest sig build
It was trying to do something with a shield that didn't exist - only occurred in a couple of builds
Threw a light on the mesh to form a truespace group - and it loaded fine
Might pay to separate all the turrets (and arms) from the ship - PCS2 has a turret autogen feature.
-
Downloaded new sig build same problems, no textures, model not viewable in other formats (solid or wire) can't edit data, and saving causes crash at end.
-
heh - your post beat my post edit
-
I'll try that later, I thought if a model had subobjects already you didn't need a light EXCEPT for turrets? (the common problem for 1 object fighters - add a light)
Edit: While I was away I converted 3 robot models from 6k-9k polys with pcs1 that pcs2 wouldn't and I didn't use a light.
They blow up fine in game no crash.
-
I'll try that later, I thought if a model had subobjects already you didn't need a light EXCEPT for turrets? (the common problem for 1 object fighters - add a light)
Edit: While I was away I converted 3 robot models from 6k-9k polys with pcs1 that pcs2 wouldn't and I didn't use a light.
They blow up fine in game no crash.
PCS2 does it by truespace group = subobject (not mesh)
I may have put you wrong. It's the group that allowed psc2 to load the Yamato mesh, not the light.
-
PCS1 has the same group requirement
if your models are not being loaded it means you haven't followed model specs probably - you were also using a very old build. and for the umpteenth time subobjects without geometry are unequivocally DISALLOWED
-
For the umpteenth time I am not a modeler(it's even in my sig)...
That model I posted has 1 group all the parts are slaved to the name. And of course 99% of my conversions are unarmed.
Regardless, is this in ANY way related to the texture issue when I try to load the .cob and see nothing???
I'm more concerned about that, then getting people later on who ARE modelers to bug fix the hundreds of meshes in my collection slated for certain mods.
-
wow... your model massively busts requirements, you know it, and you expect me to give you support?
-
well the only thing wrong with the model I can see is it's not in groups.
-
Regardless, is this in ANY way related to the texture issue when I try to load the .cob and see nothing???
With out the group the mesh didn't load - which means nothing to see.
Kazan's bit about "subobjects without geometry are unequivocally DISALLOWED" was about a question I asked.
-
Bug from a .cob import.
Turret in detail1 (turret01b) will be found before the main turret.
(http://homepages.paradise.net.nz/pcantwel/images/turret-find.jpg)
Edit: With same model using scn (separate hierarchy ordered detail0 to 3), the order of subobjects in pcs 2
is 1, 2, 3, 0.
Also finding some pmf loads are locking up at Reading BSP cache. (Same model) - without detail1-3 seem fine.
-
unglue your lods then reglue them it'll reorder them
-
Chrashing on save...AGAIN...using the latest build from your siggy...
Here's the model
http://www.ferrium.org/trashman/Stuff/Orion_NEW_TEst.cob (http://www.ferrium.org/trashman/Stuff/Orion_NEW_TEst.cob)
-
not dead... just busy with start of term and start of belegarth - i hopefully will get some work done on this once i'm settled in. Also hoping to get this job at the virtual reality applications center (VRAC) that pays sweetness for a student job (75%/hour of what i was making when i wasn't in school)
-
Sorry I've been kinda out of the loop.... burn out issues..
anywhoo....is July 10 07 the latest build?
Also, why do I have to fight the UI? Using Home and End on the Position and Normals, where you enter X:Y:Z sometimes works, other times it takes you to a different subsystem. Sometimes the program will switch to a different subsystem when your trying to setup another one. Also, same applies with copy and pasting... sometimes you have to hit ctrl+c a couple times in order for it to copy. Setting up values was faster with PCS1
*jumps up and down with joy* Autogenerate paths!!!!!!!!!11111oneoneoneone YES! That saved me a ton of time
-
Well when I save the ship after reskining it, how come it makes the file bigger?Also are you close to another release?
-
was the original file compiled by a different compiler?
-
I just over writ the file.
-
that does not answer the question
-
he means "did you use a different program (not pcs2) too convert the model?"
-
No I just rename the textures to something else then when I save over the other model its like 1 MB more.
-
you still haven't answered my question. Was the model originally from a different POF compiler than PCS2?
-
Yes they were converted via PCS1 I think.I did this to the HTL models.
-
PCS2 model sizes will be different - they're much more details and correctly compiled, plus ships with shields will have the SLDC shield collision chunk which is brand new (so new FS2 Open doesn't support it yet)
-
Do we still need to use EngGlow to get other points like eyepoint, gun barrel points...etc? Or have additional points been added like GunPoint, MissilePoint etc?
Second, with the Convergance, are the values in meters?
-
uhh.... not enough time to read whole thread. :p
before i start beggin my parents, exactly what s this one capable, and i noticed on the first page, someone mentioned not being able to see their model in the beta. i have the same problem in PCS1. and also about PCS, id that the program i texture in?
9plz forgive any typos, this computer's keyboad doesn't work to good
-
scob: your question doesn't make sense
titan: if you aren't going to bother to read the thread, and find the answers to all your questions which have already been posted, then why should we help you?
-
sorry bout that, i needed answers and i only had a few mins........ plz dont ban me :(
-
I don't have the power to ban, and if i did i wouldn't ban over something like that, just trout you one.
-
in PCS1, whats the SDL app window?
and also, when i try and do "open up a new render window", i get this message that says:
"the instruction at "0x100260db" referenced memory ay "0x00000000". the memory could not be "read""
also, isn't a render window suposed to be a viewy thingy?
-
PCS1 is end-of-life, no support is giving (that window is the render window)
PCS1 should not be used
-
gonna have too, 'till my dad comes oe and i can ask him bout PCS2. you created both versions, you SHOULD know whats going on!
-
i know exactly what's going on RTFM
-
Heya :D
Just a little suggestion. If you have time, Kazan could you update the first post. I mean put the latest PCS 2 built, some explanation and so on. I think it'll simplify the use and the time to get the latest build/news or whatever you want just by going to the first page. But, well, It's only if you're Okay.
-
Hi, (i am french please speak english easy)
I want at create a models in 3DS max9, for convert to POF i will do use PCS2 or Modelview? And where found PCS 2?
Thanks.
-
Is this to the point where I can include it in the Installer?
-
I think it is still in Beta....
-
Hi, (i am french please speak english easy)
I want at create a models in 3DS max9, for convert to POF i will do use PCS2 or Modelview? And where found PCS 2?
Thanks.
The way I do it is:
You will need to export the model to 3ds format. Open up the 3ds model in 3d Exploration, then save it to COB format. Finally open it up in truespace and set the values there (theres a faq about that somewheres, check the wiki). Then you can convert it with pcs2.
-
Couple problems I've noticed... If I load a model, import something (like paths or docking or what have you) Resave the pof, pcs2 will simply quit. I have to revert to PCS1 to import. And on that note, when I load the model into pcs1, the Glow point group properties is messed up. Someone isn't writing/reading the pof record entry correctly.
-
there was a bug in some builds causing glow point prop corruption.. it should be fixed in the latest builds. We are one feature away from release candidates and i may be able to implement that feature today, if not today i WILL do it tommorow.
-
Woohoo, updates!
-
When I try to save the Orion...
...it crashes.
Why is this?
-
there was a bug in some builds causing glow point prop corruption.. it should be fixed in the latest builds. We are one feature away from release candidates and i may be able to implement that feature today, if not today i WILL do it tommorow.
Is July 10 07 the latest build? At least it looks like it in the folder. The problem still occurs when viewed with PCS1, redglow becomes À÷ and when i reload the pof in pcs2 it comes out as È'´w_texture=whitegl
-
don't use PCS1 for anything glowpoint related.
When I try to save the Orion...
...it crashes.
Why is this?
which orion?
-
The Media VP's Orion.
-
does it crash if you remove all glowpoints before saving (just to test a theory)
and Kazan, is there something wrong with the repository? I can't seem to do updates.
-
Yes it still crashes.
-
Oh now I remember why I need to use PCS1, if i load a model into pcs2, import some stats, then save, the app simply quits without saving. Hence I convert the model in pcs2, save it, load it in pcs1 and import the settings.
-
ok, try the build in my sig, see if it works better now.
-
Man, the date of that build in the zip is set to 2002, is your computer set right?
-
Well it fixed the problem, and I like the red bullets ;)
-
Well, I re-saved some models I think were causing some crash issues with recent HEAD builds. During re-cache, it took a _really_ long time, to cache a several thousand poly fighter. Does this seem right? I mean, like 30 seconds or something, on a 2GHz machine.
-
Man, the date of that build in the zip is set to 2002, is your computer set right?
no, no it is not.
Well, I re-saved some models I think were causing some crash issues with recent HEAD builds. During re-cache, it took a _really_ long time, to cache a several thousand poly fighter. Does this seem right? I mean, like 30 seconds or something, on a 2GHz machine.
yeah, I can see that.
though there might be other problems, I found an infinite recursion issue and tried to implement a solution, though it might be causeing problems, but at least I figured out what the problem was.
-
well i'm back from belegarth Oktoberfest... i will try to get some work done too
-
Yay! Can't wait for 2.0 Final!
-
ok, I think I fixed the infinite recursion issue that was causing problems, without causing new problems. in new models look in the model comments section and check 'most polys in a single node' it should be a small number like 2, it it ever gets bigger than 10 I think we might have a problem, I doubt it'll ever get bigger than 5 though. there was a bug in the statistic code for this so if you see some huge number like 4000 in older models don't panic.
also the 'max BSP depth' should be some ware in the neighborhood of log2(polycount of most complex subobject). to calculate this type
log(polycount)/log(2)
into google. if it's more than twice what google gives you (it will rarely be as low as the theoretical limit) then there is a potential inefficiency that needs to be worked on. general rule of thumb is it should never get deeper than 20 (unless you have a model someware in the range of a million polys)
and on the subject of the statistics, Kazan if you still read this you should look at the last two statistics which have to do with the time it takes to compile a model, it can take several minutes to take care of the overhead involved with setting up the geometry and less than a second to actually generate the tree, I think we will need to do some major reorganization of stuff so that overhead is no longer needed in the future. I think I've mentioned this before, but I was just reminded of it.
-
i believe most of the overhead is converting to FS2 coordinate space, and then compiling the points list
best theoretical performance of those is O(n) and O(n*n) respectively.
-
I'm prety sure it's th n^2 part that's causeing the problem.
-
probably.. but there isn't much you can do... now that i think of it best theoretical performance is like.... O(n!) not O(n^2)
-
we could not store the polygons in our geometry as a list of independent points, but as a list of indexes to a list of shared points. that would be more like all geometry formats we are going to work with, make editing geometry easier, and solve this problem. the best theoretical performence for BSP generation is nlog(n).
-
I'm pretty sure this was already said but when I save my POFs the meshes get slightly corrupted. Collision detection on capital ships seem dead. I passed right through my Typhoon! Not to mention the barrels were nearly gutted. I'll try some other models and see if the same thing happens.
-
no, no it wasn't said, we've been working under the assumption that the BSP compiler has been working all this time because we have been asking people to try and break it for six months and no one has said anything.
now what do you mean 'nearly gutted' are polys missing? you are useing the most recent version? have you used other versions? did any of them work ok?
-
all the models i tested were working fine.. but that was under the 1 polygon per leaf mode
-
Hmm, whoops. It occurs to me that I've not actually tested _saving_ many (if any) capships once they're converted, because I'd forgotten that the BSP compiler only runs during POF save. A lot of what I'd been doing only involved just opening SCNs. Only half the story. :\
(I had taken much simpler test meshes and occasionally fighter meshes further, but nothing as complex or as large as a capship)
I recently did try a capship though, and encountered that holes-in-mesh bug Bob describes. It would only show once the POF is saved and reopened. I assumed those errors were because of bad COB data, because I hadn't built that particular mesh, but they sound like that missing polys bug. I'll give it a test now with some of the known working SCN files of past ships and see if they have missing polys once POF-ified. If so I'll post a bug report with as much info as I can get.
-
Double post, but whatever that bug was, it is apparently gone now. I just converted, saved, reopened and carefully examined 8 big models, including the one that had the weird missing poly bug previously.
I redownloaded the most recent PCS build from Bobs sig before testing though, so my only guess is that those latest changes squashed it. :)
I was checking the BSP depth and node polycount data this time too. Most had a BSP depth of 15 or 16, but the node polycount was all over the place. The TC-Tri had a count of 16, the Aeolus 10, and the Triton 8. The others (fenris, loki, lucifer and zeus) all had counts between 1 and 4.
Do you want me to upload the TC-Tri's source SCN?
-
no, no it wasn't said, we've been working under the assumption that the BSP compiler has been working all this time because we have been asking people to try and break it for six months and no one has said anything.
now what do you mean 'nearly gutted' are polys missing? you are useing the most recent version? have you used other versions? did any of them work ok?
Oh. Ok then, here is what I have:
PCS 2 says it is Jan 4 2002 00:14:16. I recall somewhere that said the 2002 thing was not right. By gutted I mean triangles are missing. One of my models had an entire engine removed! And by engine think Earth Alliance Starfury without one. When I used PCS2 on my Typhoon Cruiser I passed right through the hangar and weapons can't hit it.
I don't exactly know where a PC2 repository is but I SORT of found a way around the model corruption problem. I use PCS2 and 1 together. I set up the model in PCS2 and export a wrecked mesh and take a copy of the original and use PCS1 to transfer the data without harming the mesh.
I'll see if you have a newer version in your sig. I can't remember where I got my pcs2.
EDIT: I got the Oct 9 version and resaved a model that would've gotten the errors. The mesh error appears to be fixed. I'll test it on other models and see if the problem was fixed.
-
i released a pcs2 build in 2002? whhaaaa?
-
I think Bob's date is frakked on his PC. All his recent stuff has been dated wrong it seems.
-
that should be fixed now, I hadn't noticed it untill someone pointed it out in one of these bulds, but my data was wrong, the build in my sig should be right, if it isn't I'll have to re-upload.
-
This is what I'm seeing in 7-zip for the modified date for the files:
devil.dll, ilu.dll, ilut.dll modified on 2003-01-09 19:02
pcs2.exe modified on 2002-10-09 00:38
So the date is right for pcs2 I think, but the year is wrong still. And I guess you never bothered with the dlls or something.
-
the dll's he packed are probably a redist
-
I've ended up with different versions of those dlls over time, I figured at least one was built with/against the pcs2 base.
-
the dlls would only effect reading of texture files or startup, BSP compilation would be uneffected.
-
Right, just saying I've noticed some discrepancies in their distribution. Also, sometimes they're not even included depending on who made the build. Does Kaz make a static exe or something? If we do keep the dlls in the pcs2 directory, is there a most recent version somewhere we should be using? I know they're just an image library, but I was just curious whether they're actually needed or not.
-
i have them in a seperate archive (instead of reposting the same files over and over)... bob isn't using the same exact build of them as me last i checked.
bob.. want to do me a favor... write the code to reverse-engineer smoothing angles - make it a member function of pcs_file working on it's internal data types.... i just can't bring myself to write it right now and it's the only thing standing between us and RC builds
-
the algorithm to reverse-engineer smoothing data from POFs is going to make your computer cry
[edit]
this algorithm is going to eat your face.
-
Can't wait. Maybe it'll die and I'll have an excuse to blow my first paycheck on a new one, instead of, oh I don't know, rent.
-
the algorithm is suprisingly fast.. now that's it's implemented that means.....
RC1! http://www.hard-light.net/forums/index.php/topic,50099.new.html