Testing your builds...

#1 Here are some things that I do to check the integrity of an interior.

1. In the debug Torque (or a release version compiled with the INTERNAL_RELEASE preprocessor flag), it's good to look at your interiors in the debug render modes. In the console, use the setInteriorRenderMode() function to see the different modes. Some useful ones are 2 (highlight detail brushes), 5 (show lightmap), 7 (show zones), 10 (show triangle strips).

2. To get a quantitative idea of how your interior affects render time, type "metrics(fps)" in the console to see the framerate displayed in the top left corner.

3. Getting a good zone is probably the trickiest. A couple of ways to verify you have a good zone is to export your dif with no lights and "ambient passes through" set to 0 for the portal. Drop it in Torque and relight the scene. The zone should be black. Set the camera to it's slowest speed and fly inside of the wall. The zoned off area should disappear (it's being culled as a whole). Set the debug render mode to 7 (as above) and make sure each zone is a solid color and the portals are transparent blue. Now fly all around the zone inside the wall and make sure there aren't any "lost" faces hanging around in the walls. Sometimes you can end up with a single face zone hidden inside a wall.

Hope that's helpful.

#2 Thanks Ryan, let me just confirm the debug version you are talking about, would that be this.....
http://tdn.garagegames.com/wiki/T2D/TGBTutorials/BuildingADebugVersion

If not please elaborate more on that...thanks Ryan...

I haven't setup a debug version, I'm not a programmer. Do I need to have a license to do that. I just want to follow the rules...

#3 No, that's for 2D engine, Torque Game Builder. I can't remember if the debug version is installed along with the release version or not. In your example folder, where "torqueDemo.exe" lives, there should be a "torqueDemo_DEBUG.exe". If not, then you would have to compile it from the source code. This page describes how:

tdn.garagegames.com/wiki/Torque/vs2k5

Instead of selecting "Release" from the "Configuration" drop down in Step 4, select "Debug".

What version of Torque do you own?

#4 We have 1.52..we're indie..I didn't find the torqueDemo.exe, looks like I'll have to wait on the debug probably until I can get someone to compile it for me. I've been wanting to do this for a while but every one is doing other things...thanks for the link, I'm gonna try and talk them into doing this soon...it needs done...

#5 I have a debug.exe but it keeps halting on the splash screen loading objects and it has an error message when I bail to the desktop that says, MRandomGenerator::: randf inverted range...

#6 Someone is using randF() wrong. The way it works is you give it a min and a max, and it returns a pseudo random number between the min and max. So something like randF(2.0, 10.0) would return a floating point value between 2.0 and 10.0. The min parameter HAS to be less than or equal to the max parameter. You're getting that error because someone changed the code somewhere and put the first parameter bigger than the second. In that case, the engine throws the fatal assertion you see above and stops the program.

#7 Thanks Ryan...if I understand correctly we are not using randf, its not being used and that the problem looks to be coming from the foliagereps. Once again, I'm not the programmer so I will have to verify that, I'm just here while it's being checked out. I know I have placed many of the foliagereps in my map and that I have had many problems with the shapeReplicator and crashes Torque everytime I think about using it so I'm not using shapeRep until I understand how to use it a little better...would the problem likely be foliageRep or shapeRep?

#8 ...I'll just ignore the foliageReps...but.. I finally got in there with the debug....wow....I can only peak at like 30 FPS and it's much more sluggish in debug mode, and my structures have major problems. When I walk between the two of them in third person mode it can barely move, it isn't that bad in First Person mode...but this terrain and the structures have major problems...I knew the terrain and the structures would need tightened up but I didn't know it was this bad...heres what I've done to the terrain...

many- foliageReps, but are commented out for debugging...
1- precipitation block
1- lightning block
1 water block, but is quite large for creeks that scurry about throughout the level..
@50- small temporary tents
2-log huts
10-oak trees, placed one at a time, not with shapeRep
4-particle emitters, 2 in each hut,
6-light objects, 3 in each hut..
2-torque flags....other than the sky, sun, player and terrain itself this is my map...am I in this dire need of a new sytem?



here's a shot of the two structures I was wanting to originally test...
http://www.deanguitars.tv/userpics/lib9/huts.jpg

#9 Yeah, debug mode is going to be really slow. Since you just want to look at your interiors, just open an empty scene and drop your dif in there. It'll be slower than normal (especially relights), but it'll be fast enough to examine your interior. If you ONLY want the interior debug render mode capabilities, and not all the other debug options that are slowing everything down, simply compile a "Release" version with the INTERNAL_RELEASE preprocessor compile flag. This version should be much faster than the debug.

As for the foliage replicator, it must be your problem if it ran after you took it out. The InnerRadius must be less than the OuterRadius. The MinWidth must be less than the MaxWidth. The MinHeight must be less than the MaxHeight. And the MinSwayTime must be less than the MaxSwayTime. If any of those are not true, it would throw an assertion.

#10 Ryan..man you've thrown some help my way..I really do appreciate it...

as for the other Internal Release version of the debug, would that result in better performance between the structures...which is where most of my lag is...between the huts the fps slows all the way down to......are you ready for this.....a whopping 9 fps....wew... or do you think the structures themselves have problems..

this is what I wanted the debug for which raises the next question....which mode would be better to test the fps in as whole for the entire terrain? I know that question strays from the constructor a bit but most of my lag is with structures I built in constructor...

#11 A straight release version will provide the best performance... that's the final version that you would give a customer. The debug version lets Visual Studio (or other IDE) connect to the engine while it is running, so that you can set break points, examine values of variables, track down memory leaks, etc. It's got alot of overhead, so it runs slow. The internal_release version is just like the release version but with a little bit of debug code compiled in, like the interior debug render mode stuff, so it's still pretty quick.

Without seeing your scene in person, here's my guess as to why you're seeing such a performance hit. I'm guessing your interiors are made up of structural brushes. Since you have tons of cylinders intersecting each other, they're probably cutting each other to shreds and generating tons of unnecessary faces. You'd be able to see this in debug mode. I'd just make all the brushes into detail brushes.

#12 Ryan...detail brushes have helped the fps quite a bit, I'm still getting lag but I think most of the problem is the pc. I took a break yesterday, and today I have been tinkering with the zones...since you say that is the trickiest I have decided to tackle that first and here are the first results....

in mode 7, after changing the detail brushes they show up as white and the portal is trans' light purple.. *(the portal is not aligned perfectly with the doorway, there are spaces all around and the hut has no threshold so the bottom of the portal touches the ground)*....I relighted a few times still white...I have not placed any lights in the hut.scene and the portal is set to 0...

as for the construction process of the hut...I have been very careful to NOT bleed faces. There shouldn't be any brushes that are overlapping or entering each other, actually, most of the brushes are hovering one another looking like they are touching but are not...the shredded faces your talking about would they look like holes, cause I did have some on another build but I haven't seen on this one. Would I need good zones for some of these problems to show up first....

the demo particles are crushing fps too, I figured the prebuilt particles, etc would be a little more cleaner than what they are...

#13 I actually don't recommend zoning a structure like that... some reasons you would zone off an area would be to cull it when not visible, or to restrict your lighting to a certain area. Since you can see inside your hut from any angle, it would never be culled. Also, I don't see any reason you'd want to restrict any lighting to the inside of the hut. I don't think you'd gain anything from trying to create a zone, plus you'd probably have to get tricky to get it to zone properly.

Take a look at this to help understand zones and portals.
tdn.garagegames.com/wiki/Constructor/Portals

#14 Everything in the last post as far as zoning is strictly from what constructor has done to it, after seeing the zones were far from what you said it should be I just left it alone and since moved to something else...no I haven't tweaked the zones at all but I did add a portal to the doorway and was just wondering if it seemed ok....

I was trying to get into the mode to find the bad or shredded faces you were referring to and couldn't find any faces in the walls or anything so I think the interior is pretty good so far...

back to zoning...when I get to doing that again...when they are correct they will be black?

update...
thanks for the link...it has already answered quite a few questions...

#15 Here's what I meant by shredding... all the brushes in this pic are structural. A structural brush that touches another structural brush is cut into new faces by the all of the surfaces of the other. See how complex geometry like the sphere will "shred" any brush it touches. Detail brushes don't cut other brushes, so you end up with less faces. I only use structural brushes for brushes that will form the boundary of a zone. I make everything else details. The dif in the pic was just an example... I would never leave it like that for a game.


When you get a zone created properly, only lights in that zone will affect it (unless you set the "ambient passes through" parameter to 1), so if you don't have any lights in your zone it will be black when you do a relight. If you look at it with setInteriorRenderMode(7), the zone will be green if it's zone 1. If you have multiple zones in the same dif, they will be yellow, red, purple, etc.

#16 I will be using this thread allot while tinkering with zones....lol...thanks for the image...
yes, that was a very nice tip on detail brushes, I can even feel the difference.

"When you get a zone created properly, only lights in that zone will affect it".....hmmm...I really want some good lighting around the fireplace in some of the huts so would now be the time to think about high and low quality settings for options? I mean since there are many ways to achieve lighting effects, zoning seems to be the best way for performance...I'm probably taking that way too far but something I've been thinking about...
maybe zone a different hut for a fireplace that will have the fireplace lights just a thought...I know I do want to cull out as much as I can when not in view by the player and still achieve nice lighting effects...

I know I want to soundproof some areas so I will be taking lessons on zoning...

#17 I probably shouldn't have said that only lights in a particular zone would affect that zone. You can selectively restrict either the ambient or diffuse lighting of different light datablocks to a zone, or let them spill over into other zones. I wouldn't go crazy with this zone stuff... if you over-zone, it becomes counter-productive, and you start to nullify the benefits of it. You need to find the places that need it for a specific reason, and zone them off. Otherwise, I recommend just making everything detail brushes to keep the face count low and geometry clean.

#18 Ok..you've gotten me in the right direction and you've helped me allot...thanks for your input...I will definitely use this thread for looking back on from time to time...thanks Ryan..