[Bobboau]

pshh, that was too freaking easy, (check over pcs_pmf_cob I just committed it)

now back to the geometry filter...

[Kazan]

triangulated requirement for shield meshes is a hard-req of POF.... so are you triangulating when generating the pof?

[Bobboau]

yeah,
well actually triangulating it when reading the COB

[Bobboau]

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)

[Bobboau]

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

[Bobboau]

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!

[Unknown Target]

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.

[Bobboau]

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.

[Water]

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)


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.

[Bobboau]

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.

[Unknown Target]

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

[Water]

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?

[Vasudan Admiral]

Dude, you're implementing new stuff faster than I can test it - no fair!

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.

[Water]

Just an observation
File size seems to be larger under pcs2.
Under pcs1  - 34.1mb. The same model with pcs2  - 48.6mb

[Kazan]

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

[Kazan]

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)

[Vasudan Admiral]

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?

[Kazan]

actually looking at the code i DID think of that message

Code: [Select]

if (InputFile.Group_Count() < 1)
     return -1;

so.... you must have had a group in your file that didn't contain geometry

[Vasudan Admiral]

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.

[Kazan]

hmm.. it should be triggering a popup window.. i'll look later