DIF and the TSE update?
by FruitBatInShades · in Torque Game Engine · 11/22/2004 (2:01 pm) · 13 replies
I know this topic has been bandied about many times, but I want to raise it again.
Should DIF bite the dust or at least be updated?
From what I understand (please correct me) the original author of Map2DIF is long gone and left uncommented code with no docs. I've looked through the code and can't make much sense out of it. There is reputedly a re-write/fix going on at present, but there is no news.
With the overhaul that is going on for TSE, wouldn't it be wise to upgrade the interior rendering engine as well? A lot of useful resources have been posted that add the modifications that people are looking for. I would have thought that it would be easier to re-write that section of the engine (yes, I know its big) so that it works from a clean slate and will be commented and more OOP.
What could be done
Add transparent png support for faces.
Making two modes available should enable faster rendering for those simple items.
Mode 1 would transparency is at 0 or 1 and should be able to be blitted fast.
Mode 2 would do full transparency and have to calculate the colour multiplication of each pixel.
Bezier curves
Possibly update the rendering engine to handle bezier curves.
Decal Support
Add proper decal support to the engine. Well executed decals can save a lot of polys and give really good visual quality. Two sided decals could also be very useful for window textures etc.
Lightmaps
The lightmaps are not very good. Most people suggest increasing the resolution of the lightmaps to hide leaks. We shouldn't need to. That pushes the dif's size throught the roof and the leaks are errors is calculation. Most leaks come when you try to have dif that have world light allowed to creep in.
This problem stops a lot of modelling possibilties. You cannot have an dif that allows light into the interior, if you do the errors is the lightmap show up. I have researched this and it definitly an error with the lightmaps and map2dif. I have hand inspected map files and all faces align perfectly. The error seems to be introduced whilst portalising the floor areas.
Map2Dif
Map2Dif is a sensitive beast. It might be worth adding user selectable fix and error functions. Error reports can be set to flag up worrying items and those that actually kill the compile. It could also dump the brushes as text to the screen so you know where to start looking to fix the problem. I name most brushes so a report like:-
I raise this again because with all the new TSE stuff going on it may be the right time to try and fix these issues. Plus a map i've spent 2 days on had just gone haywire and I can't fix it. What drives me nuts about all this is that I can compile the same map into different engines and they run fine.
Personally I vote for a complete rewrite of DIF, Its got to be better in the long run to strip out all that old code, add new code in an OOP manner and comment the hell out of it.
Should DIF bite the dust or at least be updated?
From what I understand (please correct me) the original author of Map2DIF is long gone and left uncommented code with no docs. I've looked through the code and can't make much sense out of it. There is reputedly a re-write/fix going on at present, but there is no news.
With the overhaul that is going on for TSE, wouldn't it be wise to upgrade the interior rendering engine as well? A lot of useful resources have been posted that add the modifications that people are looking for. I would have thought that it would be easier to re-write that section of the engine (yes, I know its big) so that it works from a clean slate and will be commented and more OOP.
What could be done
Add transparent png support for faces.
Making two modes available should enable faster rendering for those simple items.
Mode 1 would transparency is at 0 or 1 and should be able to be blitted fast.
Mode 2 would do full transparency and have to calculate the colour multiplication of each pixel.
Bezier curves
Possibly update the rendering engine to handle bezier curves.
Decal Support
Add proper decal support to the engine. Well executed decals can save a lot of polys and give really good visual quality. Two sided decals could also be very useful for window textures etc.
Lightmaps
The lightmaps are not very good. Most people suggest increasing the resolution of the lightmaps to hide leaks. We shouldn't need to. That pushes the dif's size throught the roof and the leaks are errors is calculation. Most leaks come when you try to have dif that have world light allowed to creep in.
This problem stops a lot of modelling possibilties. You cannot have an dif that allows light into the interior, if you do the errors is the lightmap show up. I have researched this and it definitly an error with the lightmaps and map2dif. I have hand inspected map files and all faces align perfectly. The error seems to be introduced whilst portalising the floor areas.
Map2Dif
Map2Dif is a sensitive beast. It might be worth adding user selectable fix and error functions. Error reports can be set to flag up worrying items and those that actually kill the compile. It could also dump the brushes as text to the screen so you know where to start looking to fix the problem. I name most brushes so a report like:-
Error from Line 137 of TestDif.map Error Type: Face interects adjacent face Object Dump:- Brush No: 11 Tree: WorldSpawn -> Ground Floor:g[1] -> Front Door:g[12] -> Front Door:p[1] Face: 1 Map Data: ( -496 90 58 ) ( -560 90 58 ) ( -496 59.49999 58 ) BearBeam32x512 [ -1.00000 0.00000 0.00000 -992.00000 ] [ 0.00000 1.00000 0.00000 -377.70489 ] 0 0.50000 0.23828
I raise this again because with all the new TSE stuff going on it may be the right time to try and fix these issues. Plus a map i've spent 2 days on had just gone haywire and I can't fix it. What drives me nuts about all this is that I can compile the same map into different engines and they run fine.
Personally I vote for a complete rewrite of DIF, Its got to be better in the long run to strip out all that old code, add new code in an OOP manner and comment the hell out of it.
#3
11/22/2004 (3:08 pm)
I second that.
#4
11/22/2004 (3:23 pm)
Yes it is needed. Well a complete rewrite might not be nessessary but something needs to be done. The question is, has anyone who is capable of doing the work volunteered to do so?
#5
11/22/2004 (4:01 pm)
Neil: If this was done, it would have to be done internally at garage. To change/replace the dif spec will affect the whole engine. Its not something that could be done by the community.
#6
I don't know how you've missed it but it's certainly there and has been for long.
It is in the works. Just not yet.
11/22/2004 (4:04 pm)
Guys, read up. Matthew Fairfax is rewriting Map2dif as far as I know. If you check the milestones for TSE you can see that the last milestone (the milestones are being rearranged, too.. I think) is Map2dif overhaul.I don't know how you've missed it but it's certainly there and has been for long.
It is in the works. Just not yet.
#7
1. What are the main priorities?
2. Are there any feature inclusions or just bug fixing?
3. Is Rad gonna be included?
4. Please tell me the lightmaps are gonna be fixed...PLEAAAASSSSEEE
At the risk of getting shot (which I do all the time) why have I missed the thread asking for feedback about Map2Dif? or the one asking what problems people have encountered and how they solved them?
11/22/2004 (4:12 pm)
@Stefan: Hopefully Matthew will read this thread and answer a few questions :oD The million dollar quesion is "What do you class as an overhaul?"1. What are the main priorities?
2. Are there any feature inclusions or just bug fixing?
3. Is Rad gonna be included?
4. Please tell me the lightmaps are gonna be fixed...PLEAAAASSSSEEE
At the risk of getting shot (which I do all the time) why have I missed the thread asking for feedback about Map2Dif? or the one asking what problems people have encountered and how they solved them?
#8
11/22/2004 (4:53 pm)
Matt has implemented almost all those features in regular Torque on his own awhile ago actually...
#9
On a purely happier note, I have fixed the map that went haywire, yay! I had to add a few wierd brushes to avoid the error but managed to get it to work again, phew!
11/22/2004 (5:06 pm)
@Tim: are these things being included in the new update?On a purely happier note, I have fixed the map that went haywire, yay! I had to add a few wierd brushes to avoid the error but managed to get it to work again, phew!
#10
I feel confident that it's enough to make it easier for us, though.
11/22/2004 (5:55 pm)
Ya, "Map2dif Overhaul" could be mean alot, and alot less.. too.I feel confident that it's enough to make it easier for us, though.
#11
The priorities for the first stage are:
1) Improved parser - instead of choking on the first error it will try to continue to parse the rest of the file
2) Multiple .map formats (beyond Valve220 and limited Q3) - this should reduce some of the headache of
having to run everything through Quark
3) Improved error reporting
Unfortunately, map2dif can't be fixed in one fell swoop. It is going to take some time so be patient. Please feel free to continue posting suggestions here though =)
11/22/2004 (8:44 pm)
The map2dif overhaul (happening this week ;) is going to have to be done in several stages.The priorities for the first stage are:
1) Improved parser - instead of choking on the first error it will try to continue to parse the rest of the file
2) Multiple .map formats (beyond Valve220 and limited Q3) - this should reduce some of the headache of
having to run everything through Quark
3) Improved error reporting
Unfortunately, map2dif can't be fixed in one fell swoop. It is going to take some time so be patient. Please feel free to continue posting suggestions here though =)
#12
11/22/2004 (9:38 pm)
Thanks for the heads up Matthew :o)
#13
This is an interesting discovery. It appears to me that light leaks are not leaks at all in some cases. I have been experimenting and discovered some interesting anomolies. I can't tell you what they are yet, I'm trying to get some real info from the coders of the world but it seems that the lightmaps don't merge very well.
It seems that is two zones lightmaps cross, they give extra brightness to the faces of certain brushes. If you block one zone off the light anomolies dissapear.
I'll get back to you when I have more info :)
11/30/2004 (9:37 pm)
Light leaks are not always light leaksThis is an interesting discovery. It appears to me that light leaks are not leaks at all in some cases. I have been experimenting and discovered some interesting anomolies. I can't tell you what they are yet, I'm trying to get some real info from the coders of the world but it seems that the lightmaps don't merge very well.
It seems that is two zones lightmaps cross, they give extra brightness to the faces of certain brushes. If you block one zone off the light anomolies dissapear.
I'll get back to you when I have more info :)
Torque Owner Max Thomas
Max