Maplet Question
Community Forums/Developer Stations/Maplet Question
| ||
| I am currently rediscover the pleasures of using Maplet, but there's a problem that I would consider significant: When I first carve a huge block with an invisible material to create the "universe" for an outdoor enviroment (solid walls etc. inside the huge carved space), then the surfaces of the invisible huge block (that is surrounding the scene) will be lightmapped too. I am using a grid of white lights to emulate some kind of sunlight with a radius of 100. Needless to say the huge blocks textures, that are infact invisible anyway, seem to consume about 33% of the lightmap without any reason. Correct me if I'm wrong, but does it make sense at all to reserve lightmap space for invisible tris / textures anyway? If there's a way around this problem, please let me know, thanks. |
| ||
| Should I let you know if there's not a way round it? I will anyway... As far as I'm aware... There's not a way round it, 'tis bloody annoying and I think it's a real shame BRL didn't continue work on it because I thought it had the makings of an excellent leveller. |
| ||
| It would be great if BRL would open the Maplet source up for registered users. That way the product would have the potential to continue to be developed, rather than remaining at the dead end it appears to be at now. |
| ||
| I agree. Although I am not a VC++ coder, I see a lot of potential there. Eg. saving some extra information like a simple lights position file. If it is abandoned definitively, it would be a nice turn to make it some kind of open source. Like, a SDK for registered users and the limitation for noncommercial usage only. |
| ||
| I agree too. For example, would be nice if Maplet could re-import an exported .b3d level, while preserving the lightmapping informations. I usually use Decorator to apply the textures to a lightmapped .B3D level, but if I want to add a light, I have to re-start from the .maplet file - so all the texturing made with Decorator are lost. Sadly, there's no way for Maplet to import a .B3D lightmapped and 'decorated' level. Would be nice if Maplet could get again some attention in the future.. I think it's a real shame BRL didn't continue work on it because I thought it had the makings of an excellent leveller. ---------> Sadly, I agree. Sergio. |
| ||
| I was missing this too, although I am afraid this won't work for some reaons, mainly because a maplet map is a list of boolean CSG operations (carving and filling primitives), with the .B3D file Maplet may not be able to reproduce the CSG ops list because a lot of information cannot be interpreted clearly. However, I think it would be possible to import the materials from a decorated .b3d file. Maplet would then have to parse all triangles and assign them virtually to some CSG primitives - or something. I have already tried to write a tool that will load am edited B3D file and assign the textures of the original, decorated .B3D file to the new mesh, based on triangles similarity. Unfortunately, the triangles will chacnge as soon as you add/remove/alter lights in Maplet. It seems the fragmentation of the Mesh does not only consider geometry and the diffuse texture layer, but also the lightmap texture space. Probably it's possible to use such a tool to assign the textures of a mesh to a maplet-edited version of it, as long as the lights are the same. New triangles will then be untextured, so the amount of work will be limited. An other solution is not to use Maplet for lightmapping, instead use eg. SlimShady. But I have to say, I prefer Maplets lightmapping because of it's speed. Not so long ago I imported a 16kTris sene in giles and applied one directional light to it, then I deactivated global illumination and started to render. What should I say, it was dead slow, I was having dinner meanwhile. And as a bonus, I used to get a MAV after the rendeing process. Ok, fredborg, sorry :) It's likely I did something wrong, or my giles instalation is kind of messed up. I guess I should upgrade again. And I also have to say giles has a lot of very nice features. But for some reason it's always very slow for me. BTW SlimShady is slow too, plus it lacks of a LOT of things, and the result is also very dark. BTW using a grid of lights in maplet to emulate directional light (sunlight) is a nice trick and gives smooth shadow contours since they all overlap kind of. You only need to use a color other that white, eg. 128,128,128, so the addition of multiple overlapping lights will give white again. One other Note that may be useful for maplet users: Recently I used a 256*128 pixel texture (Usually I use only one texure for the map, then texture it in decrator). Using this non-square format resulted in what should I say, very bugous texture scaling behaviour in Decorator 1.8. It's really a nightmare (it scales in the size proportion, in a potenting way, eg. width*width vs height*height), so always make sure to use a square texture in maplet. |
| ||
| Maplet was the reason I wrote Droplet to add additional functionality and entity placement to Maplet. Droplet was designed to allow you to add zones, entities and meshes to a maplet map to give you a more rounded product. Decorator allowed you to monkey with the textures. With these three apps you actually had quite a bit of power, it was just a bit arsey to use three products as opposed to one. I think what Maplet needed to stop all the mesh fragmentation was to record all the operations that went on in a virtual way and then rebuild the mesh based on what the result of that would be (if that makes sense) that way you'd have fully optimised perfect meshes. Anyway... I don't think Maplets going to progress, which is a shame, but there it is. |
| ||
| A thought concerning the initial topic: It should be possible to write a tool that will optimize the lightmap texture space usage. Tracking down the textures should tell you the space that is used at all. I'm not sure if the transparent Tris are stored in the mesh at all. But it doesn't matter that much. when re-aligning the UVs of the lightmap, transparent brushes simply would be ignored. Well, right now I think the transparent Tris are not exported at all, because there is no collision! Now that is really "suboptimal", how comes they use texture space, but their tris are not exported? Well, I only speculate, correct me if I'm wrong. However, the hardest part is to realign the Lightmap UVs. I know there are some good Sources around, but probably people won't give it away. One is fredborgs, but of course, he would rather like to sell his tool than to fix competiting tools for free. This is understandable. If I find something (maybe the one of YAL), I'll probably try to write a little utility. One day :) |
   |