[Setekh]

Man, the specular brings out those great details like nothing else. Well done, Karma and Vasudan Admiral and Bob.

[jdjtcagle]

I hate to point out this, but.....



Looks great other wise....
And plus you cant notice it, really.

[Vasudan Admiral]

i think Bob just took the turrets and their locations from the regular fenris and just stuck em on for this one

i'm nearly done with the final version (and this is one of the things i fixed) - just finishing off the debris before compiling into a pof.

[Taristin]

Woo. I'll wait for the Official Vasudan Admiral™ version.

[Vasudan Admiral]

ok, nearly finished it now. all heirarchy works, and it works in-game.
however it seems that all versions of this particular mesh will crash fred and fred_open (latest HTL one). i've tracked the problem down to Code\Model\ModelsInc.h - third and fourth lines from the bottom:

Code: [Select]

#define MAX_POLYGON_VECS 1100 //6500 (7x)
#define MAX_POLYGON_NORMS 2800 //6500 (3x)
it seems that whatever this MAX_POLYGON_VECS is, it won't let the fenris into fred.

on the other hand, i added 3 zeros to the end of both the above limits (overkill probably), compiled and ran, everything the same as before, and it worked perfectly in fred and ingame, with no noticable drawbacks.
so unless a coder can spot what i can't, could someone with SCP fred access bump those limits for the next fred release plz? thanx

[Goober5000]

Originally posted by Vasudan Admiral
i added 3 zeros to the end of both the above limits (overkill probably)

Oy. That's far too much.  Find the lowest possible increase and try again.

[Bobboau]

those valuse arn't used anywere in the lates HTL builds, try this one

[Trivial Psychic]

Bob, I'm not trying to insult you or anything, or trying to say that I know more about this kind of thing (since I'm not skilled at pretty much anything you are), but I think Vasudan Admiral was refering to limits in FRED2 and not in FS2.  I only point this out because the thread you linked to discusses FS2 and not FRED.  I just assume you made a quick scan of his post and picked out a few words but didn't get the exact gyst of it.  I've done it myself sometimes.

If I'm wrong or being rude or anything, just delete or modify this post.

[Bobboau]

ah, yeah he did say that didn't he...
have you tried the OGL build of fred? it uses HTL to reder the ships (IIRC)

[Trivial Psychic]

Originally posted by Vasudan Admiral

ok, nearly finished it now. all heirarchy works, and it works in-game.  however it seems that all versions of this particular mesh will crash fred and fred_open (latest HTL one). i've tracked the problem down to...

[Vasudan Admiral]

i've tried most versions of fred i could find. all of them crash because something about the model breaks that limit. :\

and what exactly is it that's breaking this limit anyway? ie, what's a poly "vec"? Vector?

and Goober: what does having it set that high actually do? i didn't notice any framerate reductions or other bugs, and the fred i compiled worked fine.
but i'll try to find the min anyway.

[Vasudan Admiral]

well well well, look at this:

Limits at
MAX_POLYGON_VECS   4100
MAX_POLYGON_NORMS   5800
gives this:

The old shards of death.

Limits at aforementioned
MAX_POLYGON_VECS   1100000
MAX_POLYGON_NORMS   2800000
gives this:


no shards of death. and all that has been changed is that one limit. the higher limit one also ran much faster and smoothly

edit: oh yes, and this is just changing the limit in bog-standard fred. however it's actually managing with a 6000 odd poly model here. much larger than the original exe could hope to cope with.

[Taristin]

Well, that's handy...

[Bobboau]

setting it too high sucks vast quantities of memory, the vect are used for normals and points, it turns out there has never been a poly limit, but there is a point limit.

with just the defpoints alone that's going to take up 64 megs of memory, what you did. it's probly closer to 156 megs, becase the defpoints are copied sevral places

[Flipside]

Well, probably the limits can be tweaked a bit, but at least we know it can be fixed

[Vasudan Admiral]

hmm..... ran some tests, and the minimum limits i could find it will work with are

Code: [Select]


#define MAX_POLYGON_VECS           7700 //1100 (7x)
#define MAX_POLYGON_NORMS           19600 //2800 (3x)which is in ratio with the originals (x7)

however, this is seven times what the original limits were. so what in the world is it about this particular model that breaks the limit by so much?

keep in mind tho this does not appear to greatly affect framerates in fred, and it can still allow 149 of them before deciding the ship limit has been reached.
the framerates with about 8-10 of them on screen at once are slower than with the old model, but that was sorta expected with HTL models, and especially when using non-HTL (no SCP enhancements at all) fred

[Flipside]

Hmmmmmmmmmmmmmmmmm.... well, these are pretty obvious questions, and I know how experienced you are as a modeller, so you've most likely already checked, but have you made sure you have merged all the vertices together? That might account for the massive number of vecs?

Only asking coz I've forgotten to do this before

[KARMA]

well, in order to reduce the facecount, the main object is made of ~130 submodels, which mean that the vert/face ratio in a triangulized model is surely higher than the ratio of a solid object, like the models

[Vasudan Admiral]

hmm... that's probably it exactly Karma. and since there's no way to change that other than merging them and getting a 10-20 000 poly model, or deleting them, it's probably best to up the limits in FS_Open i think?

btw Flip, that would be a potential cause true, but i'm pretty sure it isn't in this case - most models with that problem have severe clipping problems, and so far this one has been perfect in fred and ingame in that regard.
(although it's now decided to keep crashing when loading a mission for some reason - something not right in the pof data i think)

[KARMA]

if solid it would be around 10-12k polys: I made the solid object first, then splitted it in submodels whenever it let me save faces, until I reached a reasonable facecount and a stable result (a longer process than expected)
As for the clipping problems, this strategy would create huge clippings in vanilla fs2, but it works fine in fs2open since Bob enhanced the z-buffer. Personally I think that the z-buffer is the best thing SCP made so far:)