PB 5.10 65535 face barrier hit by WorldShadows()

[IdeasVacuum]

Including the WorldShadows() function in code that creates a mesh of > 65535 faces causes a crash:

Microsoft Visual C++ Runtime Library

Assertion failed!

Program: ...
File: OgreShadowCaster.cpp
Line: 253

Expression: v1 < 65536 && v0 < 65536 && (v0 + originalVertexCount) < 65536 && "Vertex count exceeds 16-bit index limit!"

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)

[Comtois]

Have you a code to test ?

[IdeasVacuum]

Hi Comtois

Try adding the WorldShadows() function to your large face count example here: http://www.purebasic.fr/english/viewtop ... 78#p404478

......without assigning shadow to an object

Ensure you have nothing important unsaved because it could lock-up your PC and require a reset.

[Samuel]

I gave that a try Ideasvacuum and it seems to run fine on my pc. Although it was using about 6 Gigabytes of physical memory........
and cpu usage jumped up to about 70 percent. So I'm not sure what the problem is. Except for maybe being to much of a load on the average computer.
Sorry for not being much of a help on this. Maybe Comtoi can be more of a help.

[IdeasVacuum]

I think this is all we need to know really:

Expression: v1 < 65536 && v0 < 65536 && (v0 + originalVertexCount) < 65536 && "Vertex count exceeds 16-bit index limit!"

Ogre has a cap on the vertex count there. I think it's difficult to reproduce the crash but one has to wonder why there would be a hard-coded 16-bit limit in this day and age?

Of course CPU load is an issue, but it's a seperate issue.

[Comtois]

No crash here.

btw, i have read this :

Your mesh is over the limit for shadow volumes. You could probably change Ogre to support 32 bit vertex counts for shadow volumes, but it's not a good idea, because you'll get really bad performance using stencil shadows with such big meshes anyway. I'd suggest switching to texture shadows or reducing the number of vertices significantly.

Here :
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=31113

[IdeasVacuum]

Yep, it is an Ogre limitation, don't see why it needs to be hard coded though, should be possible to offer the app User options.

Look at the date of their response: 2007. PC's have become far more powerful since then.

[PMV]

If it sounds simple, you have not grasped the complexity.

65536 (16-Bit) is a hardware limitation of (older) graphiccards. Thats
why it is is hardcodes for them. If it crashes in your case, maybe your
hardware is to slow.

Or just post the changed example that crashes. As you have read if
someone else is modifying the source as you suggest it doesn't crash
for them. So you could have done something different even so it is
just a small codechange.

MFG PMV

[IdeasVacuum]

65536 (16-Bit) is a hardware limitation of (older) graphiccards. Thats
why it is is hardcodes for them.

That isn't a reason to hard-code the value, that is a reason not to!

[PMV]

I think you are misunderstanding this "error".
If your hardware is not able to do something it will crash. In past
you have very often a blue screen. If you know it, you will "hard-code"
a check for it to prevent it. I'm not a C++ programmer, but i know
that "Assertions" are used to check something. It is not the best thing
as this check just shows an error-message and closes the program ...
But it could be an issue of the PB implementation.

MFG PMV

[IdeasVacuum]

Not at all, again, essentially it's the other way round. If critical to it's function, code should verify the capability of the hardware it is reliant upon, rather than bringing everything down to the lowest common denominator.

An assertion should not result in a crash, though most times it is only branched out to a graceful end of program rather than a re-try with reduced criterior.

The comment from Ogre clearly states that it supports 16bit vertex counts for shadow volumes. That clearly is out of date when you consider today's hardware. It's not an issue for me, I do not need shadows, but if you are writing the next block-buster game, it might have an impact.

[PMV]

Not at all, again, essentially it's the other way round. If critical to it's function, code should verify the capability of the hardware it is reliant upon, rather than bringing everything down to the lowest common denominator.

Thats what OGRE does ... it checks what your hardware can
and activates as much as possible. As long as you doesn't
post your system specification, i and maybe everyone else
will just think that your system is just to slow.

An assertion should not result in a crash, though most times it is only branched out to a graceful end of program rather than a re-try with reduced criterior.

As i wrote, it could be a PB issue ans so it should be posted as a bug.
I had a few crashes because of assertion-messages but because it
was my mistake i have just fixed it and everything was ok.

It's not an issue for me, I do not need shadows, but if you are writing the next block-buster game, it might have an impact.

You really wouldn't want to use OGRE if your goal is a blockbuster.

[Fred]

Well

It's not an issue for me, I do not need shadows, but if you are writing the next block-buster game, it might have an impact.

You really wouldn't want to use OGRE if your goal is a blockbuster.

OGRE has been used in successful commercial projects like torchlight, so I don't know why it couldn't be the right choice.

[IdeasVacuum]

....Maybe this is an even better example of what Ogre can do:
3D Medical Simulation

[PMV]

For me, "blockbuster" implies a very huge amount of costs and with that,
you would buy one of the outstanding (and expensive) 3d-engines. I also
imply that it has a very huge amount of people who have bought it.

OGRE is still my number one choice as a free 3d-engine. And i love it.
But as that, it can't be as functional as his expensive competitors.

Btw. my hope is that my project gets a huge user-base after its release,
so of course i know what OGRE can.