Map2Dif Alpha ver 0.96

#1 What's a release of something without some screenshots?

#2 Kick ass!

#3 Great, thanks Matthew! I especially like the 'Chequered Error Tower' (CET) which obviously didn't make it into TRON :-).

#4 Cool Matt! I'll run it thru some of the bigger test maps i've collected working on the CartShop DIF exporter.

#5 EXCELLENT WORK!

#6 Nice work Matt. I ran some of my problem maps through it and the crashes stopped in game :)

I know your aware of some of this because its in the readme, but just to re-iterate.

1. Collision works on the character. but the not the camera (assume its using raycast as per comment in readme)
2. Lighting is still messed up...WAHHHH! (again, in the readme)
3. A lot more surfaces are produced than in previous versions. I assume this is the result of creating correct geometry?

I will get back soon with some real comments as I create a load of illegal geometry and see how it handles it :)

#7 Not to pick holes but I've noticed some strange geometry being produced. I'm not complaining, the map works fine, but shouldn't either the piece sticking through the floor, of the floor itself be triangulated? As it stands the blue/grey piece sticking through the floor is just passing through the dif. (So is the green one but it doesn't show up well)

#8 Mathew can you provid a Linux version, i would like to test it with the blender exporter i am working on with Joe Sulewski. (see my .plan or www.draekko.org)

Or i can always compile one myself provided the source were available :)

#9 I will be adding this Alpha version to the artist page, and soon updating the DIF features matrix to include it (and be divided in a more logical fashion)

@Fruitbat - do you have those set as detail brushes? If not, I'd recommend sending your map to Matt for testing.

#10 @Alex: not detail brushes, I'll send it to matt.

#11 @Fruit

Concerning your light leaks, are you sure your building them correctly to avoid situations where light leaks could occur? Could you post some wire-frame shots of how your brushes meet up, preferably 2-D left and top.

As you can tell from the 3rd shot down Matt posted, light leaks are usually do to improper setup. The lighting in that short is perfect, so I'm sure it's not map2Dif.

For example,. if your have your walls coming down on top of your floor brush, that's asking for a leak, etc. :)

Also, don't forget that's what portals are also for. By "zoning" off the inside of an interior usign portals correctly, you can virtually eliminate any possible light leaks from the outside, as long as you have it flagged to keep out sunlight.

Virtual caulk is a term often used to build these sort of things properly.

-Tim

#12 @Tim

I do NOT have light leaks. Light leaks I can find and fix. I am on about the lighting errors where two brushes meet. The lightmaps overexposure does not show up on a white surface hence why it looks so good ;) That image also illustrates another lighting anomoly.
The platform coming out of the door on the left of the picture has a dark grey edge to it, as do many of the other brushes if you look. I don't have the map obviously, but that usually occurs when a detail brush touches a normal brush and gives the effect of a cartoonish edge or the floor/wall seems to float a little in game

#13

Quote:
For example,. if your have your walls coming down on top of your floor brush, that's asking for a leak, etc. :)

Tim, you probably have more experience with torque interior modelling than anyone. As part of you garage responsiblities :) could you do a tutorial to create a particular building that converts without light leaks? Then you could share your knowledge and tips with the rest of us. I tried to sort all this out and offered what I had learned to the community, but I am fed up of these lighting issues. I seem to be the main person in the forums for the minute helping people with sort of things and would like to further my knowledge.

P.S. Would garage host some video tutorials if I did them?

#14 Disclaimer, it's 3am and I'm writing this quickly so I can go to sleep, but hopefully I can explain this well enough.

I'm tired of hearing about these "anomalies" people keep talking about on the forums and blaming them on map2dif so I'm going to try to explain to these once and for all and try to reiterate what people like Matt Fairfax, Alex Swansong, and the GG Staff have been saying with the help of some colorful diagrams so people understand it a bit better so there can be a stop to this mystery of lighting anomalies once and for all.

First of all, this is not Map2dif causing these wierd errors, repeat, NOT map2dif. I've had a lot of experience with map2dif, I *live* with the guy who rewrote map2dif, I know it very very well. So please, listen to this.

The lighted anomalies around edges are in fact actually light leaks even though everyone thinks they are not light leaks. The reason for this is they are actually very sneaky ninja light leaks that you wouldn't catch in an editor, specifically Quark. Quark is the main problem behind this error and the link between everyone who has sent me maps like this has in common (and I get quite a few people sending me problem maps for some reason...)

So anyhow, begin lesson:

The light leak is cause by the surface of the "floor" brush actually being lit by the sun.

I'm goin to explain this is very simple 2-d terms for simplicity, but keep in mind this error can be reproduced in many ways and many dimensions & directions.

When trying to export from Quark, quark does this wierd thing where it rounds coordinates of vertices in brushes by a very slight margin, like hundreths of a decimal. I'm talking it shifts vertices so slightly, that it's almost invisible to the naked eye in some cases.

This doesn't agree well with stock map2dif because it is extremely precise, to the bajillionth of a decimal place, so when Quark starts chopping off those decimals, the two do not agree and produce slightly "off-set" brushes. I'd love to go into more detail about "why" this error occurs in Quark, but it's 3am and there are threads upon threads talking about this error from everything to floating point values to act of god, so if you want more information just do a serach and talk to Matt Fairfax & Alex Swanson as they are the resident Quark & Map2dif experts, and I'm more interested in explaining why it's causing these light anomalies.

However, the fact of the matter is what you see in the 3D-View in the Quark Editor is not what it exports. This results in the very slight movement of brushes in such a direction that's almost invisible to the eye without extreme closeups and looking for it, hence this error is almost always overlooked.

A common way people build their walls and floors sets up the possibility for this quark exporting goof to set up "lighting anomalies".Remember, half the people who post problems with map2dif have sent me their maps at some point in time, so I know how you guys build your stuff, I've seen it!

#15 Most people who run into this error just happen to tend to all build their walls & floors like this with your walls coming down to meet the floor instead of going around it:


While this looks perfectly lined up, and leak-free in Quark, this actually is setting quarks faulty exporting to set you up for light anomalies.

What happens is this:


What is going on here is because the rounding of decimals in the export function, the brush is moved every so slightly on final export and then immediately compiled in map2dif, you wouldn't actually see this in problem in Quark and all would look fine when searching for light leaks which is why it's almost always frustating and overlooked.

In this example, I show the wall brush tucked slightly in because the vertice rounding moved those vertices slightly to the left.

Because of this, a very tiny tiny lip on top of the floor brush is exposed to the light rays being cast from the sun, and hence, map2dif thinks this surface on top of the brush should recieve light since it's sticking out and can be hit by the lightrays coming from the sun!

Hence so that tiny lip recieves lightmaps and that sliver of light will spill under the wall producing the anomaly light bleed...

Keep in mind in this example, I used a very simple 2-d example, the subtle moving of vertices on export could be moved in an 3-Dimensions and at any angle, even moved through other brushes which could cause wierd exporter problems when map2dif tries to create surfaces that are very little because of this. Some of you may have gotten Band Winding Brush Errors or similar at some point in your lives, this is actually related to this partially, Matt could explaint his a lot better than I could however.

In related news, the new Alpha test of map2dif (and eventually new release map2dif) that was just released will help counter this error. Map2difs insanely unneeded accuracy was toned down some and this should help counter bad winding brush errors, but remember this is alpha and still in testing, you may still run into some errors related to this.

#16 "So Tim, what can I possibly do to avoid these anomalies?"

Well, the safest bet is to build your geometry in such a way as you can avoid any possible situation where rounding of decimals could move your brush in a way where it will cause a light anomaly. Personally, I recommend building your walls like this:


Be sure to build your wall with some width to it too, so no paper thin wall guys. :)

By building it this way, you avoid the scenario I described above, but when workin with seriously small geometry, there is always a possibily. Keep in mind though that with decimal rounding, that it could be moved any which way, such if the above situation was reversed and the rounded decimals moved in the lower floor brush.


So hopefully this little lesson has been educational and will help you guys fix some of your problems.

Remember, map2dif is a very basic tool, it can't just generate random lighting anomalies, it's too simple to do that. When you recieve shadows or lighting in areas it shouldn't be, approach it methodically because chances are if something is recieving lighting, it has to be recieving it from somewhere. In this case, it was because of a microscopic lip that was sticking out due to an exporter glitch.

You may also notice this quark bug if you have wierd unaligned shapes when compiled, but when you look at it in quark it looks fine.

Personally, I would use Hammer or Cartography shop, but that's just me. It's said that by turning off Floating point values in Quark that this bug can be avoided, and maybe it can, but to me it just seems that it makes the problem from being obvious to hard-to-find.

For more information on how surfaces are created and cut up when map2dif compiles your .map file, I heartily recommend reading this resource.

It also explains how detail brushes work as bonus.

#17 I was going to explain the shadow anomaly too mentioned above, but I'm goin to sleep for now. :)

#18 THANKYOU TIM! No seriously, at last answers to all this strangeness. I know its late and your tired, but this is great information. On previous research expeditions I had thought the rounding errors were down to map2dif (hence the don't write floating change in quark).
You seriously should write a resource that explains all this, I found a lot of probs and how to solve them but you have matt and more experience. I have read all available info on the surface calculations but never discovered this little gem of info.
The reason everyone does their walls that way is that quark produces that layout when you 'make hollow'. Like you've said before, use hammer ;)

Quote:they are actually very sneaky ninja light leaks that you wouldn't catch in an editor,

LMAO :o)

#19 @ Tim you really could have slept first ;)
I love GG dedication.

#20 @Tim - Get that into a resource or something quick! =)