Rare Incorrect Poly Counts? (open)

[SneaksieDave]

If this isn't the right place to post this, please move it to the bug forum; I wasn't sure if you guys want DR issues tracked separately or not.

 

Even though I have no vid card to play with TDM I wanted to do something. So I was trying to get back to finishing up this list and then it occurred to me - there's no need to import them all into Blender, one by one, till I invariably fall asleep each time - I'd seen a Dark Radiant screenshot where the poly count was listed right there! Yay.

 

So I downloaded the most recent DR and tried it out. Most of the counts I have listed so far agree, but there are a few exceptions so far. For example (for each of these, I made sure to ctrl-J combine all parts in Blender, and made sure they're triangles, not quads):

 

\darkmod\props\mechanical\numberwheel_main.lwo

DarkRadiant count: 1782

Blender count: 774

 

\darkmod\props\readables\book_open1.lwo

DarkRadiant count: 116

Blender count: 64

 

Any idea what's causing this disparity? Clearly, as in the first case, it can have a huge effect.

 

Also, there's the question of built-in collision models - do they get factored into the polycount? I assume they don't affect rendering demand, since they have an invisible skin, but I'm not sure. If not, they shouldn't be included in the count, if that's at all possible.

 

I mean to come up with some feedback in general for DR soon (I've already got a few things in mind). It's looking very sweet.

[New Horizon]

I mean to come up with some feedback in general for DR soon (I've already got a few things in mind). It's looking very sweet.

 

Just wait until you get your hands on the the absolute 'latest' version. It's excellent! Now that I'm all setup in linux, I can build it pretty much anytime.

[OrbWeaver]

The polycount takes into effect ALL faces on the model, including collision meshes, shadow meshes or whatever. Perhaps this is what the issue is? Do the models you are testing contain shadow or collision meshes?

[SneaksieDave]

Not that I can see, thus my confusion (there are a few models, that when getting counts, I manually went in and deleted (locally, just to check) the collision mesh to get an accurate count - but not the two I listed above). Maybe you'd better give them a look; I could be missing something.

 

Anyway, if it does definitely include those meshes, is there a way to ignore that in the count? It really throws the 'human factoring' off, when trying to judge how many polys is too much for a scene.

[OrbWeaver]

Not that I can see, thus my confusion (there are a few models, that when getting counts, I manually went in and deleted (locally, just to check) the collision mesh to get an accurate count - but not the two I listed above). Maybe you'd better give them a look; I could be missing something.

 

OK, I will check when I get home. It is possible that it is not counting correctly.

 

Anyway, if it does definitely include those meshes, is there a way to ignore that in the count? It really throws the 'human factoring' off, when trying to judge how many polys is too much for a scene.

 

I will integrate the counting with the filtering system, so that any filtered textures are not included in the count.

[OrbWeaver]

I have replicated the problem, and it looks like the counts are totally wrong. For book_open1.lwo

 

Surface using book_cover1
 will have 22 vertices
 and 192 indices (64 faces)
Surface using scroll1
 will have 69 vertices
 and 156 indices (52 faces)

 

In Blender the book_cover1 is a simple cuboid with 8 vertices and 12 triangles, and the scroll1 has 31 vertices with 52 faces (at least that part is correct).

 

Worryingly, these numbers come directly from the C-based library responsible for parsing ASE and LWO models, which I really don't want to have to rewrite. Have you seen this problem on ASE models at all, or is it just LWO?

[OrbWeaver]

At least with the faces, it looks like they are being accumulated rather than reset to 0 for each surface.

 

Surface using numberwheel_lever
 will have 276 vertices <- 292 in Blender
 and 564 indices (188 faces) <- correct
Surface using numberwheel_wood
 will have 364 vertices <- 436 in Blender
 and 1218 indices (406 faces) <- should be 218 (188 + 218 = 406)
Surface using numberwheel_glass
 will have 16 vertices <- correct
 and 1242 indices (414 faces) <- should be 8 (406 + 8 = 414)
Surface using numberwheel_gold
 will have 208 vertices <- correct
 and 2322 indices (774 faces) <- should be 360 (414 + 360 = 774)

 

No idea what's going on with the vertices though.

[New Horizon]

Yikes, that's quite a predicament. Are the GTKRadiant guys open to offering suggestions i wonder?

[OrbWeaver]

Well I've committed what I believe is a fix - the numbers are now approximately accurate (778 for numberwheel_main and 66 for book_open1), and I cannot see any obvious rendering problems with the models - so I will tentatively say that this is resolved.

 

I have no idea what was being rendered for the extra polygons, perhaps several hundred 0-size triangles?

[New Horizon]

Hey there Orb, just wondering when our beta mappers might see a new windows release? Some nice changes lately.

[OrbWeaver]

I was going to wait for the simplified entity inspector for 0.7.0, but as there have been a fair few changes I guess I could put out a 0.6.5 in the interim.

[New Horizon]

I was going to wait for the simplified entity inspector for 0.7.0, but as there have been a fair few changes I guess I could put out a 0.6.5 in the interim.

 

Probably less work for you if you wait until the simplified entity inspector comes around. Although I'm anxious to get people using DR asap. You guys are taking the beast and turning it into something completely different from DoomED...and that is fantastic.

[SneaksieDave]

Have you seen this problem on ASE models at all, or is it just LWO?

I'd actually just noticed this ability in DR, so I haven't tried it much. And of course while I was using it, I locked my machine up (temporarily - it recovered in about a minute) due to the lack of a GPU fan.

 

As for another release? I'd welcome that. I can at least start to learn how to use it even if I can't map or render. Also, I'm gathering my feedback from trying it so far.