[Vasudan Admiral]

That's odd actually - did something major change about that smoothing algorithm? I have an old screenie of a 63 000 poly model that opened up and rendered just fine in an earlier version of PCS2, but now just hangs forever at the 'loading textures' stage.

I'm not really concerned at this stage - that was just a test model, but it is odd how it's stopped working.

[Bobboau]

was it smoothed?

[Vasudan Admiral]

Originally, no not as far as I remember.

Would the newer versions be trying to calculate smoothing upon load or something?

I'll do another test with the same model in PCS2 and see if I can come up with anything more useful, but if not I'd say don't worry about it for now. That test was my first and last experiment with the pof exporter though rather than something I'd converted with those early versions of PCS2 so I doubt it would have been terribly stable anyway.

[Bobboau]

the newer versions would be trying to calculate smoothing upon load.

and that's where the n^2 complexity kicks in. for every vert in every polygon, you need to look at every other vert in every other polygon and compare it's position, if it is in the same position you check it's normal if the normal is less than the auto-faceting angle you add them together, after checking all verts of all polygons you divide the normal by the number of normals that were within the auto-facet angle. then you start on the second vertex of the first polygon
you can see how this gets slow fast.

I actually have a geometry class partially implemented that should hopefully allow this to be N complexity. though the class it'self is extremely complex it allows for a number of algorithmic possibilities that will hopefully allow a running tab of which polygons are neighbors to which other polygons, the only problem with it is it has a lot of interdependencies. but it should allow for a minimum of memory usage and quick development of index buffers. I am worried it might not prove to be fast enough though, in which case we will just use a simplified version of our current geometry structure, which uses indexed positional components, it won't remove the N^2 complexity, but it will make the scale of it a lot smaller.

[Col. Fishguts]

What if I don't want it to recalculate smoothing data upon load (from POF) ?

[Bobboau]

it's only an issue with COBs.

[Col. Fishguts]

Hmm, in that case it just takes a whole lot longer to load complex POFs than the RC1 version did. What sorts of geometry checks are performed on POF loading ?

[Vasudan Admiral]

Ok I might be missing something here, but that n² complexity would only apply on a per subobject basis wouldn't it? Maybe even just on a 'groups of linked verts' basis? (As obviously, you can't possibly smooth over disconnected verts so there'd be no point checking them)

I ask because it currently appears to apply to the whole polycount. I have a 40 292 poly version of the same model, split into 3 subobjects of 13 506, 11 626 and 15 160 polys. The Lucifer with 12304 polys loads in 20 seconds. Logically, if PCS2 were applying the n² complexity on a per subobject basis it should take approximately 1 minute to load right? (3 sets of approximately 20 seconds)

Currently it takes 3 and a half minutes just to load the POF, which is a painfully long time. I just saved the 40 292 poly model from PCS2 and reopened it - it took the same length of time even though it should have already calculated the smooth data and everything already.

Oh - you say this smoothing calculation is only supposed to happen on COB conversion? What's happening on POF load that's taking forever then? 

[Bobboau]

I'm not sure off hand, POF loading should be fairly straight forward.
...:\

[Bobboau]

I just opened a 63k sphere, it took about 30 seconds.
do you have any clue as to what it is doing? (i.e. it's not loading a texture that takes two minutes it's loading subobjects)

loading from POF should be roughly linear, as it isn't doing much other than loading (cobs it has to do all sorts of complex things as discussed earlier)

[Vasudan Admiral]

Oh! Heh, nevermind - apparently I'm an idiot.

I re-downloaded your latest sig build to be sure I was dealing with the latest one, and apparently I wasn't. The Jan 18th build loads even a 230k poly test model in seconds, so I guess whatever it was, it's sorted now.

[Bobboau]

HAZA!

BTW for those of you interested N^2 complexity basicly would put a limit on the number of polygons somewere in the range of 6000, it isn't a hard limit, but it means for every poly you add that is another N things you have to do so somewere around there it will probably start takeing time in the minutes to load.
in the example of 6000, it means that for each poly you'd need to do 6000 things, if you add one more it means you'd have to do 6001 things for each of the 6001 polys, for each thing you add it increases the work to be done, not by one but by the number of things you have. so it's N*N or N^2. for 6000 that would be 36 million steps. now this isn't a simple number of operations here it is only a rough aproximation of how big the problem is, in reality its 36 million * some_scalar, because each step as a (semi) fixed number of substeps.
so when ever you hear someone say it's order logN or its n^2 complexity or that would take K^N time this is what they are referring to.

[Vasudan Admiral]

Hmm - one thing though: the latest RC2 build Kaz posted is also dated the same as your sig build, (hence my confusion ) but your sig build loads POFs just fine while Kaz's RC2a takes ages.

[Kazan]

odd

bob what haven't you commited?

PS: 230k model

[Bobboau]

hmmm... that's not good...


there isn't very much difference between them, I wonder what the hell is going on there.

there are no files marked as modified.

the 230k model is probably just for testing the limits.

[Vasudan Admiral]

PS: 230k model

Obviously you forget old holy snowballs all to easily.

[ARSPR]

RC2a build uploaded - contains the bounding box inversion fix.. now if you open a model and see an inverted bbox in PCS2 then you can just fix it by hand and save and it should be fixed.

Kill me if I'm wrong but I still get the bounding box issue with the Shivan Comm Node. Mantised as 0000049

[Kazan]

does the build you downloaded read RC2a or RC2 in the title? it's possible that i may not have uploaded the fix (built debug instead of release)

[--Steve-O--]

it is a game engine requirement, but there should be code that hunts down and corrects V>20 polys for you. are current PCS2 builds giving you problems with polys that have more than 20 verts?

just a message telling me about dark days brought about uncorectable geometry and its negative impact on children. it makes me feel guilty really and i have to reflect on this for a few miuntes. but then if i am persistant and hit the OK button enough, then the sun comes out and all is well. i tried something different in modelling technique to keep polies low, and payed for it dearly with a lot of >20 lines.

so i dont know if this is just how the >20 correction process goes or if its a glitch.

[Bobboau]

more likely you have concave and/or non-coplanar polygons somewhere, more than 20 points it should handle without blinking. silly error messages like that are put in places I don't ever expect them to be seen (it's sort of a joke about error messages that don't actually help you understand what is going on. they are put into places that I don't think you can do anything about the error (ie it's an algorithm error rather than a data error), I figured bizar messages would be more likely reported, and thus allow me to fix them). that one is getting seen a whole lot more than I was expecting, so I guess my filtering algorithm isn't as solid as I thought. I guess I should have it report model name and approximate location of the polygon.

keep in mind this is  relatively low level error, it's actually more of a warning to be honest. you should be ok if you ignore it, just try not to let the children get to you.