TresCom Forums

If it helps, my suspicion is that it's to do with custom meshes with subtle properties of complexity/geometry not interacted with by the Tres devs and so are creating rare errors.

TheIdiot wrote:

Code: Select all

.\Source\Lib\GeomDBase\Mesh.cpp

Line #: 930

The "code 1015" message is different, and is what results in the crash, yet I don't know what a "code 1015" even is because it doesn't describe it. My guess is that it's the "too many polys" error, but again, I didn't think that should be a problem, unless the actual face limit is somewhat lower than 3072 (the model has 3068). Any ideas?

Lee, is there anything you might be able to do to fix this? The crash seems to be occuring right at the end of the loading phase, just before the level starts, NOT in the middle of the loading bar where it would usually crash if you had high-poly models in retail.

There are two memory heaps (/buffers) directly involved with mesh data. One is used temporary when loading and pre-processing a mesh's data. That one has a max limit of 4096 polys. It also has limits for max total verts, which are based on the max poly count if they were all polygons with 4 verts. That means in theory it could run out of vertex space before hitting the poly limit.

The original limit for that heap was 2048. The original code also had an assert warning if a model had more than 1024 polys though. That's the "Line #: 930" assert above. I wasn't sure if that was a mistake in the original code where they forgot to increase the assert to 2048, or it was intended as a safety margin. To be on the safe side I kept the assert to half of the max limit, so in CE the assert would trigger over 2048. That's the "Line #: 930" you're seeing there.

The second memory heap involved, is the buffer for all loaded mesh data combined. This one has a size of 40MB in CE, and 32MB in original. I'm not entirely sure right now, but I think that is a hard limit, that very well could crash if exceeded.


To find out what's going on, I can either get "crash.dmp" files posted for each crash, and see if they give enough hints. Or you have to give me the content that crashes so that I can run through a debugger while trying to load it. If it just involves increasing some limits, by sane amounts, then that shouldn't be a problem. I could also try adding some more helpful error output, if there's opportunity for that in the code where it crashes.


There's also a heap for rendering, that limits the total number of polygons on-screen (used to be 20k, in CE is 80k). From that perspective it does make sense not to increase the per-mesh poly limit too much. After all, what would be the point in allowing a mesh with say 30k polys, and then only 2 of them could be on screen and then nothing else.

Thanks for the input, Lee, all of those details are really useful. I'll send you the level via PM and see if you can figure it out, then. I can also post the crash.dmp if it helps.

The second memory heap involved, is the buffer for all loaded mesh data combined. This one has a size of 40MB in CE, and 32MB in original. I'm not entirely sure right now, but I think that is a hard limit, that very well could crash if exceeded.

From what you've told me, I'm going to guess that that's the problem, but I'm not certain. There are a lot of fairly detailed meshes in the level, and it seems as if it is some sort of per-mesh poly limit is being exceeded when the level loads up, as tatu and I have discovered through our testing.

There's also a heap for rendering, that limits the total number of polygons on-screen (used to be 20k, in CE is 80k). From that perspective it does make sense not to increase the per-mesh poly limit too much. After all, what would be the point in allowing a mesh with say 30k polys, and then only 2 of them could be on screen and then nothing else.

I don't think that should be a problem, unless it also counts the 2D object impostors in that count. I've seen that count exceeded in the past and it definitely seems to me like a different error.

So yeah, it was running out of the 40MB mesh heap. I've added an ini option so the fm.ini can specify a larger max heap size. The level loaded after that.

TheIdiot wrote:I don't think that should be a problem, unless it also counts the 2D object impostors in that count. I've seen that count exceeded in the past and it definitely seems to me like a different error.

The impostors would count as that one (or few) poly of the impostor sprite itself. When the render buffer is maxed, CE is supposed to simply drop additional polys from rendering, not crash.

So yeah, it was running out of the 40MB mesh heap. I've added an ini option so the fm.ini can specify a larger max heap size. The level loaded after that.

Alright, excellent. Will this be in the next patch, then?

The impostors would count as that one (or few) poly of the impostor sprite itself. When the render buffer is maxed, CE is supposed to simply drop additional polys from rendering, not crash.

Hmm, so would using the Cull Distance values in an object's T-script reduce the actual amount of polys being rendered in the scene?

TheIdiot wrote:Will this be in the next patch, then?

Yes.

I thought I'd wait with an update until I've looked at adding script code for map view, in case I figure out I'd need to extend some engine-side functionality in the script system. Draconisaurus had asked about a map function. I'm waiting for the answer to some questions before doing that.

would using the Cull Distance values in an object's T-script reduce the actual amount of polys being rendered in the scene?

If the distance makes an object disappear earlier than normal then I guess so, but I'd say that's the wrong approach. The game/ini settings that control impostor and culling distance etc., should normally control the overall complexity. If a level did too much of that built into the level, then it would be harder to adjust quality settings based on what the computer its played on can handle, or potential future game versions with better performance.

If you make a level you could either target it to run decently with some standard settings, and adjust the level content based on that, or you find a recommended set of settings that work well with that level (or some combination of both). FM.INI does provide functionality to supply such recommended settings.

Lee Arbuco wrote:

TheIdiot wrote:Will this be in the next patch, then?

Yes.

I thought I'd wait with an update until I've looked at adding script code for map view, in case I figure out I'd need to extend some engine-side functionality in the script system. Draconisaurus had asked about a map function. I'm waiting for the answer to some questions before doing that.

Sadly I think it would be a long wait until Draco gets back on that. He lost his Laptop and is taking a break so could be months. Just so you know

Sorry to hear that. Thank you for the update.

If I understood it right, he mentioned it was a co-production with TheIdiot (JPDS)? I'm not up to speed. Is that a different project from the RTJP level? Is it maybe something you (TheIdiot) could answer, if I asked you instead?

JPDS (Jurassic Park: Dark Secrets) is an already released level... I think he meant it included maps which could be displayed using ATX. Personally, I never made use of maps...
RTJP (Return to Jurassic Park) is a different thing altogether.

I see. Comparing the map from the test level I got with JPDS, it is indeed the same map. That answers my questions then. That script would in such case be like a drop-in atx replacement for an existing level. I'll try to have a quick look anyway before an update.

Lee Arbuco wrote:I see. Comparing the map from the test level I got with JPDS, it is indeed the same map. That answers my questions then. That script would in such case be like a drop-in atx replacement for an existing level. I'll try to have a quick look anyway before an update.

I'm not certain what you mean by that, so allow me to clarify - JPDS is a completely different map from RTJP. The level I sent you is the first level of RTJP and is a different map from the JPDS series. You can find JPDS under the Download section on the main site, in 5 parts, if you want to test it out - the first level, JPDS~Streams, makes use of the ATX Map function.

In any case, yes, a map system would be highly appreciated, not just for JPDS, but also for RTJP and the few other ATX-based levels which used it. ATX's map system was essentially a simple key which you pushed to bring up a map of the level, and there was also support for a "GPS-like" system which displayed a blinking icon indicating where the player was. There was also an ATX ActionType which allowed you to change the current Map used in the level. With CE's functionality, I assume it would also be possible to add a definable key to the Controls menu for the Map, as you made for the Sprint script?

If that were implemented, I belive the only features still missing from CE that we had in ATX would be the particle-based percipitation (rain and snow), third-person (which I don't think should be a huge priority, considering how the player model looks in 3rd person), and the toggleable aim-dot.

Also, Lee, would you be able to look into my request a few pages ago to allow the game play better-quality/different format video files? It's not a priority, but it would be nice to eventually have support for that.

TheIdiot wrote:I'm not certain what you mean by that, so allow me to clarify - JPDS is a completely different map from RTJP. The level I sent you is the first level of RTJP and is a different map from the JPDS series.

I was unclear. I wasn't talking about the level you sent. Draco had sent me a test level with a map image, asking if I might want to look into adding support for map view.

That test map used ATX AT 102. I then also saw that you had copied the sample squirrel script for AT102 to your RTJP, so I thought maybe the request was for RTJP after all.

With the new script system there are more elegant (and customizable) ways to implement maps. That's why I was hesitant with the sample code to spend too much time on simulating the AT102 functionality. Not only maps for that matter. It would/should be possible to have more a generic pick-up system and a simple virtual inventory. Not for physical items, in that you can take them out from the inventory into the player hand, but still. In theory maybe even physical items would be doable, but that's more complicated and not something I could spend time on at the moment.

Also, Lee, would you be able to look into my request a few pages ago to allow the game play better-quality/different format video files? It's not a priority, but it would be nice to eventually have support for that.

Maybe some day, but it's quite a bit of work for very limited gain, so I don't have any immediate plans.

Huh confusion abounds lol. I do wish to say for my part that Lee's not superman and can't do everything

The update is available now.

You can add the following to the RTJP fm.ini

I've added a demo implementation of (one way to do) maps to the RTJP scripts. I didn't include the TGA files you already have in the zip. Make backup copies of your current nut files.

This implementation doesn't use ATX AT 102. Instead you define all the map info in "gamescript_inv.nut". There currently is some made up map definition as an example, you'd have to change that or comment it out.

To make a map pick-up item there's the MapPickUp script in "instancescript_items.nut". The T-Script params for that are documented in the nut file. Basically all you have to do is assign the MapPickUp to the map object in the game, tell it the ID name of the map, and you're done. You can then change the map image name, tweak the params etc., in the script file without having to re-edit the level file(s).

It supports any number of maps.