[Kazan]

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

[Nuke]

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.

[Kazan]

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

[Vasudan Admiral]

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:



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.  

Also, is saving as pof supposed to be tested at this stage as well? If so, I have a rather...interesting...bug to report.

[Kazan]

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

[Nuke]

is it at all possible to put hard lines between (truespace) materials?

[Kazan]

it not longer has a mapping to the COB/SCN's materials when it's doing smoothing calculation

[Kazan]

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

[Getter Robo G]

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.  l8tr!

[Bobboau]

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.

[Getter Robo G]

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. 

[Kazan]

please write up a report for that bug in the PCS2 mantis (link in sig)

[Bobboau]

http://ferrium.org/mantis/view.php?id=1

I could stand haveing my account upgraded there BTW.

[Kazan]

upgrading your account

[Bobboau]

ok, new build from me

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?

[Bobboau]

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.

[Kazan]

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) 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) 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.

[Bobboau]

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.

[Kazan]

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

[Bobboau]

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?