separate aas run

[grayman]

Is there a way to separate the creation of proc, cm, etc. from the creation of the aas files when dmapping?

 

I'm hitting the malloc failure more often now. Sometimes I'm able to clean up the map, but I find myself doing more debugging than creating these days, and that's frustrating.

 

My current malloc failure is in the aas part of dmap. It creates all the other files just fine, then bails out when it starts the aas creation. I'm thinking maybe I can run aas separately, which would allow me to hopefully bypass the memory issues. Maybe.

 

Any hints would be appreciated.

[Fidcal]

Yes, dmap noAAS <mapname> and runAAS mapname.

 

http://www.modwiki.net/wiki/Dmap_(console_command)

http://www.modwiki.net/wiki/Commands_(Doom_3)#AAS_.28area_awareness.29

 

Sounds like you're hitting the max complexity.

[Serpentine]

If you're running into malloc issues its usually because you have badly portalled areas.

This usually happens when you have a hub area (middle of the spiders web) and then areas connected to it are portalled either badly, not sealing or leaking back into the buh which creates a mess and runs into complexity issues.

 

If you want someone to take a look at what's going on, let me know.

[grayman]

If you're running into malloc issues its usually because you have badly portalled areas.

This usually happens when you have a hub area (middle of the spiders web) and then areas connected to it are portalled either badly, not sealing or leaking back into the buh which creates a mess and runs into complexity issues.

 

If you want someone to take a look at what's going on, let me know.

 

Thanks.

 

I've checked the portal boundaries and all seems well. I'm not seeing into spaces I'm not supposed to see.

 

I'm closing in on the problem, which is caused by func_static trim around the top of a building. Take it all out, no crash. Put it all in, it crashes. Since the trim is all func_static, it should have no bearing on portalization. There are 8 pieces of trim, none of which crosses visportal faces.

 

I'm currently taking them out one-by-one, to see which is causing the crash.

 

To clarify my initial post, the proc file is created, and neither the cm nor the aas32 file is created. So it's crashing either in cm creation or aas32 creation. Don't know which is done first.

 

 

 

[Serpentine]

Hmmm, are you by any chance using horizontal VP's up there?

[grayman]

Hmmm, are you by any chance using horizontal VP's up there?

 

No.

[grayman]

Removing all the trim worked this morning.

 

Removing the trim piece by piece until it's all gone (again) crashes.

 

Comparing the two *.map files, they're the same. Rerunning the earlier one now crashes.

 

"dmap noAAS" crashes

 

"dmap noCM" crashes

 

"dmap noAAS noCM" succeeds. If I follow this with "runAAS" in the same session, it crashes. If I quit, restart, and do "runAAS", it succeeds. In the first case, AAS is reading data already stored in its data structures. In the second case, it reads the data from the proc or map files (don't know which). So there's definitely a memory-handling problem that AAS trips over if it has to read from data structures left behind by the process that creates the proc file. Map complexity tickles the bug.

 

Well, I guess I'm off to recreate the problematic area brush by brush, since I don't want to abandon it.

[Serpentine]

Just remember, I'm happy to have a look... Do have a few free hours atm.

[aidakeeley]

I'm starting to get the feeling that mappers are going to maybe have to start creating multi-mission campaigns rather than complex single missions? Seems like memory allocation and deallocation bugs are built-in to D3?

 

I know it's got to be easier said than done at this point, grayman, but if you are having these problem just getting compiles I imagine the missons themselves will choke even some to level machines. Maybe you might start thinking about if/where you could split the mission rather than Visportal it?

 

Just a suggestion for consideration.

[Serpentine]

Its unlikely that chunking the level into multiple parts will solve it.

 

And now for some complete theory-craft and speculation.

The only time I've seen this issue was with the visportalling of Sons of Baltona, in the release version they work fine for the most part and only cause crashing during playing, however once I started to simplify them and optimize some of the remaining ones there were times when the aas compiler(or whatever you want to call it) would get abused as it was possible for the whole area above the mansion to be open if one portal was open, from there it would have about 30 adjoining areas which all had like 2-3 areas making a huge graph; which then all have to be recursively processed(I am going on guesswork now, however it makes sense to me... perhaps greebo or Tels knows more) however due to this happening its possible to create a loop, it doesn't take much thinking to realise that a loop is going to do very bad things. Once this happened it would just hang doom3 until I realised that I needed to make 100% sure that the area above couldn't be opened like that. In this case I could lower a large sky portal brush in the same outline of the mansion. Problem solved.

 

I've had similar encounters on my own maps, but that experience always told me to look for possible leaves that would have dangerous branching, and I'd fix them up in 1-2 compiles and never investigate further.

[demagogue]

I've noticed func_static trim doing fishy things before too (really slowing down performance, killing portals). I was suspecting they might affect the normal brushwork around them, like bugging up the rendering where there might be a sliver or z-fighting between them, which might open a gap between leafs and be like an internal leak (?), then bug up other stuff from that. So even though they aren't BSP themselves, they still might bug up BSP-type stuff ... was my theory anyway. Or something like that. I was never sure because (in my case) I just changed the func_static back to normal brushes and it stopped the fishiness, so I didn't investigate.

[grayman]

Back to normal here.

 

I backed up a bit and moved forward again.

 

In the end, I was able to retain the troublesome trim, and I converted some halfway-up-the-building trim to func_static. This mid-trim has been around for a while (in worldspawn form), so I doubt if it contributed to the problem. No major changes to the architecture were needed. The order of the brushes is rearranged; maybe that helped.

 

I'm nearing the end of this map, which is probably a good thing. A few more weeks and it'll be ready for beta testing.

 

I have considered breaking this into two maps, and might end up doing that. Will have to study docs on changing maps and how to get the maps to "talk to each other", since you'd have to go back and forth between the maps, not just linearly forward.

 

Thanks for the comments and the instructions on how to run w/o cm and aas.

[Mortem Desino]

It's also true that to best utilize func_statics, you should seperate your trim so it's as convex as possible.

 

If you have 8 pieces of trim circling the perimeter of a building, and you turn the whole 8 pieces into 1 func_static, the location of the origin (likely either inside a different visleaf, or smashed inside some brushes) can cause dmap and runtime issues.

[grayman]

It's also true that to best utilize func_statics, you should seperate your trim so it's as convex as possible.

 

If you have 8 pieces of trim circling the perimeter of a building, and you turn the whole 8 pieces into 1 func_static, the location of the origin (likely either inside a different visleaf, or smashed inside some brushes) can cause dmap and runtime issues.

 

Thanks. Will watch out for that.