Please welcome gile[s]!
Community Forums/Showcase/Please welcome gile[s]!
| ||
| Hi, Finally I'm able to say that my secret project to take over the world is almost done :) For the past 1½ years I've been working on a global illumination / radiosity lightmapper + editor. And now the time has come to release a public beta version! Go to the site, to read more, see a full feature list, and download the beta version!   gile[s] is a global illumination / radiosity lightmapper, capable of rendering high resolution lightmaps fast and efficiently. gile[s] features an easy to use editor, that allows you to place models and lights without fuzz. Unlike most lightmappers gile[s] handles models of arbitrary complexity keeping smoothing groups intact. With gile[s] you can even paint directly to the lightmap, and mix and match vertex lighting and lightmaps as you please. gile[s] lights up your worlds. |
| ||
| Amazing this looks awesome, im @ work right now so i cant test the beta but it looks awesome.... wow.... |
| ||
| Mikkel - I just downloaded your Dot 3 Lighting Example (via your Giles post)- When I ran it, It comes up with a "Memory access violation" because the "Entity type (head.x) does not exist" and then triggers a C++ runtime library error (application requesting the Runtime to terminate it in an unusual way) - what's wrong - the head is there and it seems a valid file? - is the code currently working for you? |
| ||
| darklordz: :) puki: Maybe your graphics card doesn't support Dot3 mapping? |
| ||
| Hiya, That looks stunning! you are shooting yourself in the foot not having at least a couple of demo scenes included with the package so we can test though. [edit] So far I'm having problems as I make my levels tiny in scale for floating point reasons. The world scale is entirely up to the user and your controls are too sensitive. Please add a configuration or preferences menu with control sensitivity. This would include movement speed and mouse rotation. Another thing: no rendering when there's no lights! one more thing I would like to see is to be able to drag-select some things in the scene and only quickrender selected! These are omissions that I hope you'll correct because this is definately something I will possibly purchase. In addition to this, about your export - I would very much like to retain all the current normals information as well as being able to specify exactly which uv channel and texture number it is exported with - for example, lightmap is exported on uv channel 2, texture id 5... I know I'm demanding but this application is so good, it needs that extra push. [edit]: also I need to wrap the mouse around the spinners like in max :) |
| ||
| You can now download an example scene, more will be available soon! |
| ||
| Yeah, the head.x file is a bit dodgy on some hardware. I had to run it through Unwrap3D to make it a valid file. Seemed to work fine then. This looks excellent, Mikkel. What GUI did you use? |
| ||
| Very nice work Fredborg! Easily the best lightmapper I have seen done in Blitz. I tried it out with a number of scenes and it seemed rock solid. The only minor complaint I would have is that you can't undo paint strokes when painting directly on a lightmap. How much is the full version likely to cost? Edit - another slight niggle - if I select an object, and then go into paint mode with the object still selected - it seems random what parts of the scene you can paint and what parts you can't. I would expect to be only be able to paint the selected object. |
| ||
| Oooooo Nice! :) GUI is good too! |
| ||
| ...configuration or preferences menu with control sensitivity. This would include movement speed and mouse rotation. User preferences, are already on the list. no rendering when there's no lights Why? The reason you can render when there are no lights is that you can illuminate everything by indirect light. Or are you saying it doesn't render with no lights? one more thing I would like to see is to be able to drag-select some things in the scene and only quickrender selected On the list. I would very much like to retain all the current normals information as well as being able to specify exactly which uv channel and texture number it is exported with - for example, lightmap is exported on uv channel 2, texture id 5... Normals, are exported. Currently lightmaps are using uv channel 2, and texture layer 2. But there is no reason, you shouldn't be able to configure it on export...Might look different afterwards though... What GUI did you use? homegrown, might release it some day :) (I tried using BlitzUI, but I needed a bunch of special stuff, so I ended up writing my own (2 or 3 times actually :)) The only minor complaint I would have is that you can't undo paint strokes when painting directly on a lightmap on the list :) How much is the full version likely to cost? This has not yet been finally decided. Edit - another slight niggle - if I select an object, and then go into paint mode with the object still selected - it seems random what parts of the scene you can paint and what parts you can't. I would expect to be only be able to paint the selected object. The painting system will improve :) You will also be able to hide models, so that you can paint behind them. |
| ||
| Rob is suggesting that it shouldn't render with no lights (or at least take no time to render). As there is nothing useful to render. [OOPS ANSWERED ALREADY] |
| ||
| The reason you can render when there are no lights is that, you can illuminate everything by indirect light. Try making a model self illuminated, it will light up the rest of the stuff! Or by using the skylight, which isn't a light (in the model sense). But for this to work it needs to gather some stuff, which is going on in the direct light pass, such as self illumination, opacity etc. However the packing time spend, will not be used on the next time you render, as the lightmaps have already been arranged. |
| ||
| Hey cool - and I mean your / giles[s] website! ;) Looks ace... OK, now I'm off to DL'ing this thingy... |
| ||
| I must say that I like the chosen name and the design and pictures on the website. All very cool. Would you be interested in a slot/link on www.playerfactory.co.uk ? |
| ||
| Well, even if it seems to be a nice peace of software, the name GILES is allready taken, with a trademark too. Look here: http://www.gameinstitute.com/products.php And thta for at least a year or two. Sorry to point you into that. Michael Hartlef |
| ||
| But this is gile[s]. |
| ||
| Another request: Backface blocks light option. What happens when we model is, we often want to save on huge amounts of lightmap texture space. To do this, we delete as many faces as possible. However this can have an adverse effect when the time comes to calculate lightmaps. So I propose a double sided face option. The backfaces will not be used in the lighting calculation as all (as now) however, you'll tell it to block light as if they did exist... what do you think? |
| ||
| Sure, no problem. It actually was like that once, but I changed it...Probably by mistake :) |
| ||
| i downloaded it it looks good ! :) |
| ||
| Fred, do you do spillage? That is, once one lightmap is used up, it goes onto the next lightmap, which gives us a constant lightmap quality. It would be extra cool to specify some sort of quality threshold so we can control how many lightmaps it uses for the whole scene. |
| ||
| But this is gile[s]. so it would be fine to name my next company MICRO[SOFT] ??? Mmmh, that could be something to make money with. :-) |
| ||
| Sunshine et al: Thanks :) Rob: Nope, I thought about something like that. And actually it did this in a very early version, but the big problem is that if people don't know what they are doing, they will end up with something completely useless. Half the time, even I couldn't set a proper quality threshold. Another thing that nagged me about this, was that the user might end up with a whole lot of extra surfaces, that would slow down render time, in their final application. So I decided to let gile[s] worry about that, and just do everything auto-magic-ally. I think this is by far the best solution, as it allows both the new user without any idea about how lightmapping works, and the skilled user, excellent results with ease. A future version will allow you to lightmap individual models, so that they ignore the material settings. This should give enough flexibility for everyone. Mike: Lol :) I actually don't think it is possible to register a human name as a trademark. The ™ symbol is not the same as the ® symbol. They have different meanings, and legal implications. But thanks for the heads up! |
| ||
| Freborg, here's a suggestion which a lot of max users will absolutely love! B3D Pipeline is essential for exporting scenes from max. There is nothing close to it. We have complete control over all the settings etc, for example multitexturing, shininess... and detail maps. *But* there one really cool extra. He has something called pipeline extensions. What happens here is, when the scene is exported, he converts all the lights and settings into pivots and stores them in the b3d file. If you were to parse these - we would never need to add or position a light again! all we would need to do is go through the scene and tweak them one by one! Supported lights are omni, directional... and so forth. Perhaps you can talk to pudding@... about this? I'm sure it'll increase Gile[s]'s appeal ten fold! If you added currently-selected lightmap rendering (for selective testing) with the above, then we could end up with a commercial-quality powerful max to game pipeline! Count me in as a potential customer (& beta tester too if you need one!) edit: email corrected! |
| ||
| ASE supports everything :) Without the need to use the special blitz material in the B3D pipeline plugin. Just export as ASE from Max, and throw it into gile[s], no questions asked! It loads: smoothing groups, transparency maps, vertex colors, reflection maps (if they are bitmaps), lights, etc. Everything you need really. |
| ||
| Potential customer here too, and I haven't even tried it yet. Managing lightmaps in Max is a right-royal pain. |
| ||
| And for all the lightwave and alias users: LWO and OBJ support is coming, courtesy of Lee Page aka TeraBit! |
| ||
| The question is, how much of a B3D file do you preserve? I would ideally like my texture layers and brush settings preserved, after all Gile[s] is *only* there to lightmap & provide radiosity IMHO. If Gile[s] starts messing around with my texture layers then this is a huge assumption. It's vitally important to be able to load a level into Gile[s] and export it back out as B3D with *no* changes to anything but the vertex colours and a lightmap on UV channel 2. I don't think thats unreasonable... If you can do that then it's perfect. All you need to do is add a MERGE file so I can merge the lights. I'd use pipeline (sorry nothing beats it) for the geometry, shininess, alphas, textures (up to 8) and so forth, and ASE to merge the lights in! |
| ||
| The only thing NOT preserved in the b3d file is that if a texture exists in layer 1 (counting from 0) of a brush it is pushed to layer 2, everything else is preserved. Obviously subsequent texture layers are pushed one slot as well. The reason for applying the lightmap to layer 1, is that it allows you to apply a lot of effects/textures on top of the lightmap, without destroying either. If you look at the supplied spaceship tunnel scene, the lights embedded in the brush are on top of the lightmap texture. This is only possible, when doing it like that. Ohh, and of course you can merge a file, it's right there in the file menu :) [edit]Darn, I just realised there is a bug in it :) Ohh, well. You need to create something new, and then delete it, to get the model and material lists to update.[/edit] |
| ||
| I would like an option to specify where the lightmap texture is, then all these issues are in the hands of the user. Currently you are > < this close to making everyone happy. I feel that the lightmap channel and lightmap texture slot should be left up to the user. If you put it in preferences, then once a user loads a level or exports a level, it obeys the setting in preferences. One more thing... you would ideally have a texture blend for the lightmap texture on export - for example modulate2x or multiply or just alpha... you cannot assume you know best in this case. |
| ||
| This sounds reasonable :) |
| ||
| Well? where do I pay? :) |
| ||
| And for all the lightwave and alias users: LWO and OBJ support is coming, courtesy of Lee Page aka TeraBit! Oh goody goody... I don't have problems using LW for my lightmapping needs, but if something comes along that makes life even easier, well... I saw that you can create pivots also inside gile[s] and there was "extra info" text area and "model type" stuff in it too... can use these as a level tags, ie where to put monsters, boost-ups, ammo etc? Can I define custom meshes for the pivot "model type" or something? Can I export that info out - separate of the level/texture info? Is there "statistic window" or something about how many and how big lightmaps were created, and preview of those lightmaps? Is the "auto expand" meant for calculating lightmap info over the edge of the polygon (but so that it does not mess adjacent pixels) or what it is? Can gile[s] handle boned .B3D? |
| ||
| One more question: can you, on the textures panel, specify a texture to be a gobbo? That is, it projects a shadow based on it's color? I would use this for a walkway, or mesh grilles and so forth. It's not a problem if you can't. If you can't, can you specify objects as being shadow casters only? that is, they don't get uvmapped and they don't use up uv space - they are there only to cast shadows... I know I'm demanding :) |
| ||
| saw that you can create pivots also inside gile[s] and there was "extra info" text area and "model type" stuff in it too... can use these as a level tags, ie where to put monsters, boost-ups, ammo etc? Can I define custom meshes for the pivot "model type" or something? Can I export that info out - separate of the level/texture info? The custom properties can be used for whatever you want. You can write scripts, flags, keywords, etc. They can be exported in a seperate text file, or be included in the name of the entity, when exporting to b3d. Custom properties can be used on all model types. Lights can be exported as pivots, with extra info in their name, or as a seperate text file. Is there "statistic window" or something about how many and how big lightmaps were created, and preview of those lightmaps? Not yet, but there will be something like that. But you can use the 'Lighting Methods Window' sort of :) It's available from the 'Window' menu, or in the 'lighting methods' group in the material settings. Is the "auto expand" meant for calculating lightmap info over the edge of the polygon (but so that it does not mess adjacent pixels) or what it is? When using low resolution lightmaps, ie. 256x256 with a lot of polygons, it is impossible to avoid, a little bit of edge tearing. The auto expand feature is there to remove this. Normally it's not really nescesarry, but it's nice to have it :)You can also go into the 'Lighting Methods Window' and expand or blur a lightmap manually. Here you can also see what lightmaps, are used and how big they are, and resize them, create new, or delete them. Can gile[s] handle boned .B3D? gile[s] can import boned meshes, but not animation, so I'm not sure it's useful for this. You will loose vertex weights and animation upon export. This may be resolved in future versions, but is not on the top of the list. One more question: can you, on the textures panel, specify a texture to be a gobbo? That is, it projects a shadow based on it's color? If I get your question then yes. Create a new material (or use one already there), apply an alpha or masked texture to it. Set the material lighting method to 'None', and enable only cast shadows in the properties below. Apply the material to the model.The 'None' and 'Vertex' lighting methods, do not take up any lightmap space. One thing to note, is that materials with no lighting methods, are assumed to be fullbright, when rendering global illumination so it's a good idea to make them not affect the GI rendering, or make them dark. |
| ||
| A bug: in the parking lot scene, you cannot paint on the walls for some reason. Wanted some graffiti :) A omission: I would like a seperate undo just for painting, or simply make sure the paint doesn't affect the underlying lightmap (don't know if it does) until I export as B3D. In other words it would be nice to keep things in layers if you know what I mean - maximum modification. Not essential though :) |
| ||
| I'm annoyed at my computer. I might upgrade so I can do all this fast... but of course if you add drag selection so we can render selected I will be your bestest friend... |
| ||
| You need to disable the 'Angular Falloff' tick box, and enable the 'Affect All Models' tick box, to paint totally freely. The Angular falloff, is there to make sure, you don't paint on the wall if you just wanted to paint on the floor. Oh, and try redownloading the scene, there was a bug in the file :) Drag selection will be coming, the render selected only, is a bit more tricky. Repacking a single model will affect the entire lightmap, so it might give problems... |
| ||
| Well on my pc it can take very, very long time to do the parking lot scene. No slight on your ability to code because I think you've done an excellent job. Even Quark allowed mappers to select just a portion to render. I was thinking perhaps an overlapping bounding box you can move around and it only renders whats inside. Whatever you do, it'll be a great help to people on machines less than 1GHZ. I think that it will be a great help to anyone actually - especially when levels start getting big and useful! |
| ||
| I was thinking perhaps an overlapping bounding box you can move around and it only renders whats inside. Not a bad idea! It would mess up the global illumination (probably), but be great for direct light previewing. Officially on the list :) |
| ||
| Exellent! To sum up my feature request list: - preferences for controls and camera clipping (it's jittery on small levels and you can see through walls) - preferences for setting the lightmap texture layer (1-8). This affects all future imports and exports. (a must for stubborn people like me who want to add loads of details) - bounding box fast light quickrender preview (a must for the snail) - double sided faces: light is blocked by the backface. I often model in an optimised way like your scenes but an outside light such as the sun would blat all over that. - specify the lightmap blend mode (lightmap should show up under textures after you render so we can modify it like the rest before export) |
| ||
| I can get these results already from inside 3DSMAX, however it is slightly tricky. The main reason I might be interested (depending on the price) of this app is because it could save me some time. How much will you be charging Fredborg? |
| ||
| Fredborg mentioned earlier the price hasn't been finalised yet. |
| ||
| Wow! This looks really awesome, nice work... Downloading now... IPete2. |
| ||
| - preferences for controls and camera clipping (it's jittery on small levels and you can see through walls Done. Grid size preferences are in as well. - double sided faces: light is blocked by the backface. I often model in an optimised way like your scenes but an outside light such as the sun would blat all over that. Done. A bug had caused it to stop working :)And, no, the final price has not yet been decided. |
| ||
| is the ability to block lights by culled backfaces always on or is it an option to toggle? |
| ||
| Setting the material to Two Sided, blocks the light. So I guess you can call that a toggle :) |
| ||
| but I'll have about 20 materials or more in the scene. So thats 40 toggles to do if I save it back out untoggled (just in case it forces double sided in the b3d file or do you ignore that?) In any case, thats a lot of toggles. Would like an option you know... :D |
| ||
| No problem. |
| ||
| This is super sweet. I hope the price is affordable. |
| ||
| Very nice bit of software! |
| ||
| A bug: you can drag dialogue boxes and tool windows far above the visible window area. Once up there, you have no way of getting them back down :) |
| ||
| Tip: quickrender is slow! instead, use normal render and disable Global Illumination. Make the lightmap size 128x128 too. It's then a bit quicker. Needs selective rendering too then we are all set :) |
| ||
| Grrr, I really wanted to have a play with it. But no, what happened is: - the PC completly blocks for a while when I start the render. - the graphics mode magically switches to 640x480x4 (yes, 4 bits, 16 colors that is!) - I try to kill that zombie -> Kaboom, crash. So after 2 reboots it's enough for this time. Hope next versions will work on my computer, as it really seems very nice (when it works that is :-/ ). |
| ||
| Whats your hardware? |
| ||
 Now, how's about that modulate 2x? :D |
| ||
| Whats your hardware? Mother board: Asus P4PE CPU: P4 2.4GHz GFX card: Geforce 4 TI 4200 OS: WinXP SP1 Really, nothing exotic, I'd even say very very common config. |
| ||
| I was wondering if you might include a scripting language. My levels are comprised of a number of building block objects postioned through out the level. I'd like to be able to load objects at specific positions and create lights at specific positions using a script. My current light mapper does this but It looks no where near as good as yours. |
| ||
| Rob: Quick render, uses the same settings as the normal rendering, but doesn't bring up the render window. So once you have set your preferences, just hit the quick render button. I know the name implies it does something else, but that's it :) Well spotted on the window dragging thing! Caff: Neato! Bring it on! Koriolis: Strange, my PC is almost the same as yours. Only I'm running Win2000 and have another motherboard. You're not running dual monitor, or some other not so normal stuff? What scene were you trying to render? When it is preparing the lightmaps on complex scenes, it may seem to do nothing for a while. Could that be it? Arbitrage: I'm sorry but this won't be included anytime soon. But you could write a function to save your level as B3D relatively easily. There might even be some ready made stuff in the Code Archives. |
| ||
| not running dual monitor, or some other not so normal stuff? Nope. When it is preparing the lightmaps on complex scenes, it may seem to do nothing for a while. Could that be it? Nope. More precisely, while I understand it can be unresonsive (though I think it's a pretty bad thing that it hogs the entire computer for more than 30 seconds - and when I say completly it's completly), the problem is why does it change my graphics mode? (and also why did it block again - apparently forever - when I try to kill it?) |
| ||
| Kinda late joining in here, but I just wanted to say this is looking great,... definately interested if the price is right. I just skimmed throught this, so I may have missed some things, but I have two questions. 1. Is there a way to pick a color from the current lightmap when using the paint tool? If not I'd like to see it added as an option,... you could pick the current color, then modify it slightly for more subtle painting. 2. Is there a way to view the lightmap? (or is this just not enabled due to the demo?) Thanks! |
| ||
| Ho-humm... request, sort of: groups. I have a level(s) made out of several smaller blocks like "room - connecting corridor - room" style that I have modeled inside Lightwave using layers so that every block is on it's own layer. It would be so *neat* if gile[s] could load this lump in so that it could preserve the separation of blocks, ie export every LW layer out as unique .B3D, as I need to keep them separate for occulusion purposes. I could also live with option to import several source files for GI'ing and tag them automatically or manually so that they will be exported as separate files. Also it would be nice if gile[s] could optimize lightmaps so that it keeps the maps specific to one block if possible... Oh, and being able to import several source files (with positional control) would be real handy; you could load in a "room" and few prefabs like crates, pipes etc and do the GI and export the whole chunk out as ready-to-use level block. |
| ||
| Pongo, you cannot view the lightmap. You can pick a color when painting by using the right mouse button. |
| ||
| Koriolis: That's really strange, I have no idea why it does that! The only thing I can think of is the GeForce driver...I'm using 44.03 and it works fine. I can understand if you do not want to torture your machine more than you already have, but it would be great if a solution could be found! Pongo: You can right-click while you are in paint mode, to pick up the color. There is no way of viewing the lightmap, but there will be something similar to the texture viewer. Darn...Beat to it by Robster :) Mustang: An 'Exported Selected' option is on the list, so that you can export only certain parts. I guess this is really what you are asking for? I haven't had a time to look at the LWO format, so I'm not totally sure about this layer stuff :) I can think of one way to get gile[s] to apply different lightmaps to each block. But you need a bit of manual work to make it function. This would mean that you had to load each block in seperately, then it is automatically assigned a lightmap (+ or vertex lighting depending on some material settings). Then you would save out the block as a .gls file, and then merge it into the complete scene. This will give each block it's own lightmap. I'm not sure what you mean by positional control. But you can merge multiple scene together. |
| ||
| A projected release date we can look forwards to or 'when it's done'? |
| ||
| I would say within a month, but don't shoot me if I miss it, by a week :) I've got a major exam in the middle of December, and hope to get it out before that, but I can't promise anything. |
| ||
| Coo... and you go and tease like this? I hate you. |
| ||
| I would say within a month Like xmas time? Damn... there goes the money I reserved for my wifes xmas present :/ [just kidding!] An 'Exported Selected' option is on the list, so that you can export only certain parts. I guess this is really what you are asking for? I "need" the ability to load many sub-chunks, GI them, and save out the exact sub-chunks I loaded in... and preferably those sub-chunks would have "intelligently" applied lightmaps, ie as few as possible per chunk, and not any lightmaps that "overlap" multiple chunks (if possible) I haven't had a time to look at the LWO format, so I'm not totally sure about this layer stuff :) Layers in LW are just different parts of the object - bit like layers in PhotoShop. I can think of one way to get gile[s] to apply different lightmaps to each block. But you need a bit of manual work to make it function. This would mean that you had to load each block in seperately, then it is automatically assigned a lightmap (+ or vertex lighting depending on some material settings). Then you would save out the block as a .gls file, and then merge it into the complete scene. This will give each block it's own lightmap. OK, this would be enough I guess, IF the merged scene can be saved out as separate chunks (ie like the bits were when loaded in for merging). I need to keep these bits separate for (code made) occlusion, one big merged level is no good for that. Maybe if gile[s] could do optional tagging of imported stuff when you merge GLMs? Then it would know after GIing etc how to chop the beast to bits when you want to save out the bits? I'm not sure what you mean by positional control. But you can merge multiple scene together. I meant that if you could load "prefabs" or merge .GLSes, you could position them after loading... and save out as one chunk. But this is really not "needed feature", just nice-to-have. |
| ||
| Perhaps an 'export clusters by model name' option could be useful? Like all models starting with A would be in a seperate B3D file, and all models starting with B would be in a...etc. That shouldn't be too hard to make, and be fairly general for all types of scenes. |
| ||
| Hi again, I cannot get masked textures to cast shadows correctly. I ticked mask and alpha, giving a perfect see-through grid, however shadow casting was wrong. This is with a tiled texture. A wire mesh. What could I be doing wrong? -feature request- Would you consider adding rendering properties? An entity would have: -renderable this is normal -hidden this is hidden and no uvs or lightmaps are applied (for our dummy objects etc) -hidden but casts shadows this is great fun! no uvs are calculated and no lightmaps are applied but the object's shadows are cast onto other geometry. |
| ||
| Ahhh, yes. The only limitation of the rendering engine as it stands: Tiled textures (in the sense they are scaled in the texture settings) are not supported, I guess I should have told that. This will be corrected in a future version! The render options for objects, will be included along with the 'override material settings' stuff coming. In the meantime, you can create special materials and apply them to the models in question. You can always reapply the original materials. |
| ||
| Damn this tool will be optimized as hell if most feature requests are implemented! I will surely buy it, nice work Fredborg, keep it up! |
| ||
| Painting becomes very slow on some levels. Painting doesn't look like it's being painted directly onto the lightmap? |
| ||
| i tried... the capabilities great but too damn slow... |
| ||
| Rob: The painting has not been optimized yet, it relies on a very basic intersection routine. I will switch over to using the rendering engine for this in a future update. This should speed it up dramatically, at the cost of a very slight delay when starting to paint for the first time. I also have a few tricks to speed up the rendering engine :) The painting is applied directly to the lightmap. Akat: Sorry to hear, you're not satisfied. Could you explain what is too slow? The rendering, the interface, everything? |
| ||
| Well done Fredborg! Had a play with this fine tool this morning, I must say it is very very impressive... Possibly the best looking blitz l-mapper utility i've seen yet. Come on with the full version! I can't wait much longer.. :) |
| ||
| I can wait if it's too expensive - I have driving lessons to pay for at the moment plus bills so waiting a bit will give me a chance to save up :P |
| ||
| The LightWave conversion function will preserve layers as sub entities of eachother. Layer 1 Layer2 Layer3 So layer operations will only need to retrieve the child entities. |
| ||
| Perhaps an 'export clusters by model name' option could be useful? Like all models starting with A would be in a seperate B3D file, and all models starting with B would be in a...etc. That shouldn't be too hard to make, and be fairly general for all types of scenes. Maybe... but it would have to be something else than starting letter of the model name. Usual case IMO is that you have your level bits named like this if you are doing things "properly": Level_docks_pier_00.b3d Level_docks_pier_01.b3d Level_docks_office_00.b3d Level_city_bar_00.b3d Level_city_bar_01.b3d etc. so you would have to use the last two digits or something? For example if you merge in the following: Level_docks_office_furniture.b3d Level_docks_office_00.b3d Level_docks_pier_14.b3d Level_city_bar_00.b3d Level_city_bar_01.b3d And if you have: checkbox for "export clusters by model name" inputbox for "cluster name mask" inputbox for "export name" You could then use "Level_city*.B3D" as a "cluster name mask" and "TheRest.B3D" as a "export name" which would then export out these: Level_city_bar_00.b3d Level_city_bar_01.b3d TheRest.B3D (which would include Level_docks_office_furniture.b3d, Level_docks_office_00.b3d, Level_docks_pier_14.b3d) |
| ||
| A particularly nice feature would be a blur brush to 'smudge out' cracks and errors in the lightmap? :) |
| ||
| Mustang: Phew... Ok, this would require some reworkings of the GLS file format... My idea was that it was the actual model name, and not the file name, that was used for this proposed cluster export. Because normally when doing larger projects, I give each model a prefix, that indicates where it belongs. I can however see the usefulness of your method. I don't think it will be ready for the release of gile[s], but I will put an extension in the file format, to make sure I can implement it without any problems (for you :). Caff: A blur brush is on the list, of future upgrades. It will be implemented along with an overhauled painting system. --- Price --- As for the price of gile[s] it will be around the same price as a new game. This means 40-50€ (Euro), I hope you all find this acceptable. And of course upgrades are free. |
| ||
| phew, Fredborg, I think thats a bit too expensive for me... |
| ||
| Alrighty then :) What would be in your price range? |
| ||
| Fredborg, I like the app and the lightmap results are great, but I have my own editor and currently place my own lights and call YAL, to do the lightmapping, would you ever produce a function based version, so that people could use your system like YAL? |
| ||
| Nope. It's a huuuuuge program (even just the rendering engine) :) Perhaps at some point I could do a system so that you could call gile[s] from Blitz (or another language) and pass a script to it, using something like Koriolis' BVM. But this is waaaaay off, so don't hold your breath :) |
| ||
| 40-50 euros sounds reasonable to me. |
| ||
| Hi Fredborg, I think 35 euros is a good price. 40+ may alienate users who would otherwise buy. It's your decision. So when can we start thinking about buying it? |
| ||
| 30 to 35 euros |
| ||
| I would pay 35 euros/dollars. |
| ||
| Id gladly pay 100 EURO for this one if I had the cash :) |
| ||
| But you don't have the cash. |
| ||
| Mustang: Phew... Ok, this would require some reworkings of the GLS file format... My idea was that it was the actual model name, and not the file name, that was used for this proposed cluster export. Because normally when doing larger projects, I give each model a prefix, that indicates where it belongs. I can however see the usefulness of your method. LW does NOT have model names... layers are the bits that the make up the model - which then usually has only a filename. So house.lwo can have walls on layer one, door1 on layer 2 etc but they don't have a names... You CAN name layers like you can do in Photoshop though, but it's not what you usually do at all. Using filename based "clustering" is maybe easier, and it is universally and always working choice. But it might be enough if there would be a choice to either export ALL merged stuff out as one "entity" or export them all out exactly like they were when loaded in for merging - they just would have gile[s] generated lightmaps and other material tweaks applied. I don't think it will be ready for the release of gile[s], but I will put an extension in the file format, to make sure I can implement it without any problems (for you :). :) As for the price of gile[s] it will be around the same price as a new game. This means 40-50€ (Euro), I hope you all find this acceptable. And of course upgrades are free. Well... 35€ sounds good, but I would "gladly" pay even 40€-50€ - IF it has all the features I need. As I can do all what gile[s] can do and more using LW's radiosity baker (although it's more painfull manual work etc) there is not much point spending cash for something that does not make my life *much* easier, ie be "perfect" app for my game needs... and what I need is of course something that makes lightmaps and lets me tweak (Blitz3D) materials & settings. |
| ||
| I think 35 euros is a fair price for this. |
| ||
| cheapskates ;) |
| ||
| We are cheapskates :) but when can we purchase..? |
| ||
| im sorry - maybe the interface too slow coz of my comp or the polys for my upload model were too much... btw - i love the 3DMax interface u made, eaiser to understand |
| ||
| Possible bug found (or maybe it's just my keyboard) When in paint mode, if I type a number I get an error if I press the 0 key on the numpad. (all other numbers seem fine, and the 0 on the top of the keyboard works fine. But I cannot type in the number 10 with the numpad without getting an error stating it needs a positive number. |
| ||
| Wonderfull! But, to be usefull to engines other than blitz3d you need document&publish the gls file format. |
| ||
| Rob: Soon! Akat: Ok :) Pongo: Well spotted! There is a problem with the numpad! But it's fixed now :) Steve: As soon as I get time I will implement exporting to other formats, such as .x, that should allow other people than Blitzers to use it. But I think I will make the gls format public as well, I just need to make sure it is the way it's supposed to be :) |
| ||
| Fredborg, have you tried this on complex/large levels (which is what it's likely to be used on)? |
| ||
| Yes! It's slower of course, but the times are still reasonable. I usually disable shadows and gi, for the first few renders, to get the light intensity and coloring adjusted. Then turn on shadows, render and save. Then I can always reload the scene and render the gi. You can do this by turning 'clear before rendering' off, and then only rendering gi. I've had a scene of an entire airport, with a huge amount of planes, render in less than 30 minuttes on a good quality setting. That was close to 300000 polygons. Obviously it was an outdoor scene, so there weren't that many individual lights. A thing to note is that it's good practice to make the attenuation of lights fit the scene, ie. if you have a lamp inside a room inside a town it's stupid to make the light attenuation infinite. Then gile[s] will need to calculate things that aren't really important for the final result. |
| ||
| Yeah all my lights are approporite to the scene. I don't use gile[s] to actually place or set attenuation - that is what max and ASE is for! however the strangest thing happened. Importing with ASE bugged half the lights. I think it may have been due to a missing material so more on that later. Probably nothing. I am looking forwards to the tiled texture mask fix because a lot of low poly scenes I have depend on it... Also, the bounding box render thing! I'd love to move and size that box and only render whats inside... that would truely rock! Of course I can go to sleep for the final render ;) |
| ||
| What is the default grid size in gile[s]? It is not adjustable? I model everything so that 1 unit = 1 meter (in Blitz) and I think that my level was *considerably smaller* when I loaded that for testing... all movement (speed) seemed to be also bit "off" (fast) because my scale was different... any chance of getting somekind of "global scale multiplier" that would affect the grid and user control speed, clip planes etc (adjustable front/back)? Also would be nice if that would affect the light etc "wireframe marker" sizes too :) |
| ||
| It's advisable to use target lights in max, sometimes my code can't extract the correct rotation from free lights :( The 'backface cast shadows' render setting is in. Along with a 'Direct Illumination Multiplier' thingie, that let's you adjust the brightness of all lights in the scene at once. Preferences for grid size, and movement speed is in as well! In the beta version the grid size was 10 units, but you can adjust that now. Camera preferences are available as well :) The light icons, rely on the radius of the indvidual lights. I have not really eplained this, but the radius is used for producing soft shadows. The larger the radius the softer the shadow. But just use the radius for adjusting the icon size, if you don't want soft shadows... |
| ||
| My next feature request is a 'buy' button... |
| ||
| Lol...I'm not sure I will be able to implement that ;) |
| ||
| The light icons, rely on the radius of the indvidual lights. I have not really eplained this, but the radius is used for producing soft shadows. The larger the radius the softer the shadow. Ah... of course. Sorry 'bout that dumb comment :) Are you going to do somekind of manual (.pdf, html, .txt) too, sort of "quick start"? |
| ||
| Ah... of course. Sorry 'bout that dumb comment :) No problem, I'm quite amazed at how few questions, there have been about the usage of the program...Must mean it's well designed :) Are you going to do somekind of manual (.pdf, html, .txt) too, sort of "quick start"? Yes, I have started on a full manual, but it takes quite a while to explain all the stuff. There will also be a 'getting started' chapter. |
| ||
| I'm quite amazed at how few questions, there have been about the usage of the program...Must mean it's well designed :) ...Or gile[s] is so complex prorgam that without "Getting started" manual ppl don't get very far ;P Are you going to release new Beta-build? Like which would have all the improvements / additions you have made recently? At least I'd like to get my hands on that as the initial beta-release has quite a few important things missing. |
| ||
| ...Or gile[s] is so complex prorgam that without "Getting started" manual ppl don't get very far ;P Maybe :) Are you going to release new Beta-build? Like which would have all the improvements / additions you have made recently? At least I'd like to get my hands on that as the initial beta-release has quite a few important things missing. Yes, a new beta will be available soon. The newest version will always be downloadable as a save-disabled demo, which simply needs to be registered to make it fully functional. |
| ||
| yeah lets hope the release goes smoothly or it'll be known as pile[s] ;) |
| ||
| It don't work on my computer. I can run the app, and load the parking lot fine. I can fly around the parking lot changing textures, and moving stuff no problem. If I try to lightmap then things start going wrong. I have tried 3 times and had to reboot every one of them. Basically I start rendering and watch the initialize progress bar get to 100% (takes about 5-10 seconds) Then nothing happens... at all. The last time I tried I left my pc for about 10 minutes and still the progress bar hadn't got off the 0% value. I tried closing the app, and ctrl, alt, deleting but the computer froze totally (the mouse wouldn't move or anything) This happened every time win 2000 Geforce 4 Athlon XP 1900 512Mb It's a real shame cos I would quite happily pay 35 euros (dashes over to xe.com - that's £24.50 all you brits) - yep i'd pay that. It just has to work first... nothing major :) Also you should let people set the screen size. It's way too small at the moment (on my 1600*1200 monitor) I look forward to your next release (in the hope it works :) |
| ||
| Hmmm, the mysterious bug returns :) Sounds like it's the same thing Koriolis suffers from. I'll take a look and see if I can figure it out, I can't think of what it would be, but there might be something pesky going on :) Also you should let people set the screen size. It's way too small at the moment (on my 1600*1200 monitor) The maximize button on the window doesn't work?[edit]Does it only ever say initializing, or is it saying something else first? |
| ||
| The maximize button on the window doesn't work? Um - ok :) I'm so used to blitz apps running in non resizable windows that I didn't bother looking... lol. So how did you get that to work then? Does it only ever say initializing, or is it saying something else first? Can't remember. I'll have to crash my computer to find out :) Be back in a couple of minutes. |
| ||
| Does it only ever say initializing, or is it saying something else first? What I did (and what happened) Goto render menu, and click render. Up pops a render dialogue and a bunch of options. Hit Render. I have a feeling something ,ay pop up after this but it appears and disappears so quickly I can't see what it is. Then I get a progress screen with two progress bars. Initializ(ing ?) and Total Render progress. The initialize one goes to 100% no problem. The other doesn't change. Does that help? |
| ||
| Does that help? Yes, very much! This should make it much easier to spot what it is. Thanks, I'll let you know if I find it :) I'm so used to blitz apps running in non resizable windows that I didn't bother looking... lol. So how did you get that to work then? Some userlib magic :) I get the size of the desktop, and set my graphics mode according to that. Fetch the blitz window, using GetActiveWindow() (user32.dll), and then modify the window using some other userlib command. After that it's simply a question of getting the current window size, and then move the graphics about according to that. I'll post some code later...Now I'm off on a bug hunt :) |
| ||
| Some userlib magic :) I get the size of the desktop, and set my graphics mode according to that. Fetch the blitz window, using GetActiveWindow() (user32.dll), and then modify the window using some other userlib command. After that it's simply a question of getting the current window size, and then move the graphics about according to that. I'll post some code later... Ooo, I can think of a use for that! ;) I've got most of it. It's the window modification bits I'm missing! For what it's worth, I get the same 'nothing happens' issue with the parking lot. The Spaceship scene works lovely though! |
| ||
| Fredborg, dét ikk' så ringe endda ;-) |
| ||
| Ben & Lee: Check the code archives! Ok, I can't figure out what's causing the lockup on your machines...It may be a dodgy file, but I can't be sure. I checked the code, and everything looks fine, but there may be a single number that needs changing. I'll take a closer look tonight. I know it's asking a lot, but Ben could you give it a go with the spaceship scene? Hansie: Nej, det er godt nok :) |
| ||
| Just to clarify. My machine does not lock up. The results of the render just do not show up. Other than that everything appears normal. Perhaps it requires more than 64 Meg of Video Ram? Oh. The code archives stuff.. Very neat! Thanks! |
| ||
I just discovered this yesterday and knocked up a few models for testing purposes...SWEET!! Cant wait for it... |
| ||
| Terabit: If you downloaded the parking lot scene, when it was just added to the site, there was an error in it. Try redownloading it, or reapply the lightmap on each material. Somehow some of the materials had a non existing lightmap...Whoops :) Psionic: Woot...Good stuff! I'll hurry up getting the full version ready! |
| ||
| Ah.. Re-downloaded the parking lot scene and everything is ok. Works now. Very nice indeed... |
| ||
One slight problem maybe... |
| ||
| 8) Mysterious...I'll take a look tonight. |
| ||
heres a quick pic of the GI/Radiosity test I just did, you can see it clearer in the second pic, on the undersides of the platforms they are picking up the blue from the floor and the ceiling is picking up some red from the walls...very nice! |
| ||
| Gorgeous. |
| ||
| I've just tried the spaceship one. That does exactly the same. Very frustrating (probably more so for you) Fingers crossed you find the 'wrong' number :) BTW thanks for the resize window demo. Very cool. |
| ||
| Ben: I can't seem to find any errors...But I think it might go into an infinite loop or something, though I have absolutely no idea why. The moment it stops is when it starts to split the geometry, this is pretty heavyweight, and uses a whole truckload of memory. Currently I'm using banks, but I'm gonna give it a shot and convert it to arrays instead, in the hope that will cure it. And a quick update: - The registration system is done, thanks to the good Lee Page. - When merging a scene, a lightmap selector appears so that you may create a new or choose an existing lightmap, to apply to the merged models. - The numpad bug has been fixed. - A lightmap viewer is in. - The select texture layer for lightmap is semi working. - A few other quirks have hopefully been ironed out. - I have fired an email off to pudding, to see if he'll let me in on the innerworkings of his b3d extensions. - The gls fileformat has changed to make it easier to implement Mustangs, export by import name thingie. - The price will be *grabs calculator* 39.95 Euro, but an introduction offer will be available :) I think that about wraps it up...Release date? Soon! |
| ||
| It looks like a nice app. But as you can see in this shot: There's a lot of light bleeding through walls under ledges. I worked to fix this in YAL, and got some good results, though it still needed more tweaking because there were some errors. But I hope you try to fix that because it seems a shame to go to all the trouble to make a nice editor with radiosity lighting even and then have it marred by unacceptable visual artifacts that you'd have to try to design your lighting around. Those artifacts destroy the illusion of a solid world. I can also see the dark edge artifacts on all the concave edges in the parking garage screenshot. It's hard to see though cause you used high res light maps. But it's there. That at least is not too much of an issue cause sometimes it can make the lighting look better than it would otherwise. Unreal used the effect to it's advantage. |
| ||
| In my opinion light bleeding is not such a big issue. You only tend to notice it if you go looking for it. |
| ||
| There's a lot of light bleeding through walls under ledges. Yes, but the lighting in that scene is probably rendered with the standard global illumination settings, which are there to provide speed, and not precise renders. By tweaking the parameters, it should be possible to remove such artefacts. And if not, you can always touch them up by painting over the errors :) ...concave edges in the parking garage screenshot. It's hard to see though cause you used high res light maps... If it's the top screenshot you're talking about, then the lightmap for all the geometry together is 256x256, hardly hires...But I do have a few tricks up my sleeve, so I may be able to remove it completely :) |
| ||
| And if not, you can always touch them up by painting over the errors :) Please say that you were joking! It's NOT possible to "photoshop" lightmaps unless you have very simple geometry and low-res lightmaps (in which case you don't really need them at all). But seriously speaking bleending is much less noticeable with decent lightmap rezz and of course most game levels are less garish than the test ones Psionic posted (I mean the red-blue-brown one). And texturing them also fades the bleeding :) |
| ||
| I was thinking about small errors. Which it IS possible to correct using the paint mode in gile[s]. But it needs to be imporved to be a 'good' solution, I agree on that :) Here's a shot of the lightmap viewer, so you can see how it packs the maps. The lightmap has been blurred, so it's a little fuzzy around the edges :)  [edit]One thing to note on that screen is that each section of the building (each arch) is a seperate model, but when packing the lightmap gile[s] performs a continuity check on all models, and groups similarily angled and continuous polygons together. This minimizes the space needed for each polygon, and reduces render errors. |
| ||
| Viewer and maps look cool... have you tried / seen this page and method for packing lightmaps: http://www.blackpawn.com/texts/lightmaps/default.html And how does gile[s] handle REALLY difficult geometry like L, O or X shaped parts / poly-groups... do those just "waste space" on the lightmap (ie is there only "bounding-box" method for reserving space from the lightmap)? |
| ||
| Yes, I think I have looked at every way of packing a lightmap :) That method is good for simple box like geometry, but horrible for organic geometry. The method I'm using packs the map very tightly, so that spaces inside C,O,L,X,B,A,E,R,Q sections ;) are filled up completely by smaller polygon groups. The next update will include the lightmap viewer, so that you can take a closer look :) (I'm in school right now, so I can't post another screen) |
| ||
| The method I'm using packs the map very tightly, so that spaces inside C,O,L,X,B,A,E,R,Q sections ;) are filled up completely by smaller polygon groups. Wo-hoo! I must see this with my own eyes before I believe! :) But if it does that, it's a really good thing... I may have to buy this thing if you don't stop revealing all the goodies it has! I guess I'll have to do one REALLY complex test level / scene and see what gile[s] is truly made of... one thing I know Lightwave is going to be better at least is that it can have luminous textures too in addition of "true" lights, like "emergency exit light strips" and such that are on the texturemaps. |
| ||
| I guess I'll have to do one REALLY complex test level / scene and see what gile[s] is truly made of... 1's and 0's mostly :) one thing I know Lightwave is going to be better at least is that it can have luminous textures too in addition of "true" lights, like "emergency exit light strips" and such that are on the texturemaps. I'm sure Ligthwave's renderer is better than gile[s] :) But you can do that in gile[s] as well. In the material settings, you can define the self-illumination of a material (it's located just below the color settings). When rendering GI this will emit light. If it's a very small area that emits the light you may need to increase the 'GI sample density' to 30-50% to get a good effect. |
| ||
| One thing I couldn't find in the demo was a method to just turn the lightmap off (or delete it) without re-loading the map. |
| ||
| One thing I couldn't find in the demo was a method to just turn the lightmap off (or delete it) without re-loading the map. Go into the materials tab, and scroll down to the 'Light Properties' group. Click on the 'Lighting Method' button (probably says 'New Lightmap'), and select 'None' or delete the lightmap. You can do this individually for each material, though deleting a lightmap will affect all the materials that use that lightmap. You may also create a new lightmap, and apply it to the material. The apply button is the one on the left just below the list. BTW: Does the grid, and stuff work for you? I saw another post that uses the same method, where you said it didn't work on your Matrox card? |
| ||
| I'm sure Ligthwave's renderer is better than gile[s] :) Yes, it's a better renderer if you look at the render quality only... but the soft costs little bit more too :) And game developers usually want to have other things too, like some Blitz spesific material tweaking stuff and apps that make game developing as easy & painless as possible - gile[s] seem to rule in that department! And there is one REALLY annoying bug in the Lightwave 7.5 - when rendering to texture (ie baking lightmaps) it does NOT respect any smoothing groups; everything becames like they would have 90 deg smoothing angle or something... can't believe that it has such a big bug. We use MicroWave plug-in that gets around this and is a better baker anyway (and faster) but that plug-in alone costs whopping $499! http://www.evasion3d.com/mw_intro.html I hope they fix these things for the coming Lightwave[8]... But you can do that in gile[s] as well. In the material settings, you can define the self-illumination of a material (it's located just below the color settings). When rendering GI this will emit light. If it's a very small area that emits the light you may need to increase the 'GI sample density' to 30-50% to get a good effect. God damn you - it seems to have everything! Now where's my VISA... |
| ||
| Small bug (latest beta): I was entering an ambient light value, when I got an 'error: value must be positive' message and the program bombed out. Are the preferences to changed the grid size/mouse sensitivity in there yet - if so where? |
| ||
| A new beta is coming which have fixed that particular bug (I'm sure you typed using the numpad :), and has the grid, mouse speed, preferences stuff in as well. |
| ||
| Good stuff. I'm having great fun playing with the beta. And no I wasn't using the numpad...I never use the numpad, strangely. |
| ||
| Hmmm, so maybe it won't be fixed :) |
| ||
| Damn, I can'r recreate it now. It's one of those things I guess. |
| ||
| @Fredborg BTW: Does the grid, and stuff work for you? I saw another post that uses the same method, where you said it didn't work on your Matrox card? Unfortunately not. But its not something anyone else has found a fix for either. :/ I did actually upgrade to an nVidia card (twice - dont ask) but I can't seem to keep away from my Matrox. Maybe things will improve when I upgrade to WinXP. Some other comments on Gile[s]: a) Will it be possible to set it up so it automatically creates a fallback (lo-res) lightmap simultaneously? b) Quick render (in demo at least) should be called Slow Render (:P) - will Quick Render be configurable in the full app. I like the way that in Max you can setup 'Production' and 'Draft' settings for example. |
| ||
| a) I guess there could be an export option, that saved a lo-res version of the lightmap. But you could do this in a paint program as well... b) Quick Render uses the same settings as the normal render, but just doesn't bring up the settings window :) There will soon be an option for quick render to render 1/2, 1/4, 1/8 resolution of the normal render... |
| ||
| >>b) Quick render (in demo at least) should be called Slow Render (:P) - will Quick Render be configurable in the full app. I think I saw it mentioned above (long thread to search through,... that the quick render is the same as the normal render,... just without the dialog boxes, so it's not actually a faster render. |
| ||
| Fredborg - i suppose I asked about the simultaneous lo-res lightmap thing cos as you are aware, in a full game you will have lots of levels (or chunks of levels) to lightmap. Every little process you need to do might not take very long for one map but can really all add up when you do it for even a handful of maps. For this reason also, I would love to see a lightmapper that takes a bunch of existing maps (with named light pivots/objects etc) and batch process them, creating all the necessary lightmaps etc. There is so much waiting around with lightmapping that it really can be a painful process IMO. |
| ||
| Can't the lightmap just be copyrected to an image buffer and have ResizeImage used on it? That would produce a low res version of it! Or even texture a quad with it on fullbright and then copyrect the results from the backbuffer. |
| ||
| Slight problem - I loaded in a b3d file that was textured, deleted the texture then applied some new materials to it from within Giles. When I tried to lightmap it, the progress bar filled up in about two seconds, displayed a percentage that was something like -27878547894% for a split second and then nothing was displayed. I'm not sure what's up, but I can send you the b3d file if you like. |
| ||
| MasterBeaker: I'll see what I can do! But as TeraBit says, it's just a question of resizing an image/texture. simonh: When creating new materials, they are not automatically assigned a lightmap. You need to do this manually. It's a known 'sort-of-bug-but-not-really-a-bug' that if no materials with lightmaps assigned, and no materials with vertex colors assigned, gile[s] still tries to render it. The -whatever% comes from the fact that gile[s] tries to calculate how many pixels out of zero it has rendered :) [edit] I've put in a check that tells you there wasn't anything to render, and gives you a hint, so you don't get confused! |
| ||
| Ah, I've sussed it now, thanks Fredborg. |
| ||
| SOME people are just too god damn productive. |
| ||
| Hi Fred, have you answered my email? ;) |
| ||
| You should know! |
| ||
| feature request: objects can have a flag where I can set it to recieve shadows but not cast shadows. in fact these should be tickbox flags in object properties, eg. [/] cast shadows [/] receive shadows [/] visible so if I wanted to just recieve a shadow from others but not cast shadows... [ ] cast shadows [/] receive shadows [/] visible or just use the mesh to cast funky atmosphere shadows: [/] cast shadows [ ] receive shadows [ ] visible |
| ||
| Don't worry it's coming, but it will (probably) not be ready for the first release. |
| ||
| Firstly, hi there Fredborg, You have a very nice app here, very nice indeed. Some truly great results can be had with little effort and at the end of the day thats what we all want :) Small bug, If you create a light and then change it`s type, it`s name for example spot, is not updated to the new type of light that you have selected i.e. ambient in the models list. Also it would be nice to turn off the light placeholders (like you can with light falloff)and have the option to set the colour of shadows. Also the ability to change the background colour so that different coloured models (i.e. grey)showed up better. Apart from that I`m a very happy chappy. Jason. |
| ||
| You can change the name of the model in the 'Basic Properties' of each model. A name is only given to a model at creation time, but you can change it at any time. The background color thing is not a bad idea! Don't know about hiding the light icons (it might confuse people), but it would be easy to do, so maybe :) Ohh, and thanks :) |
| ||
| I still can't use it :) but a feature I would like added is the ability to use selection types. In Max you can change the selection groups so you can select anything/ light/ objects/ pivots. Playing with the parking lot demo I found it hard to select the lights and kept selecting the surrounding meshes (light casing/ ceiling) Any news on an updated version? I'd appreciate it if you would email me (address in sig) when/ if it's done so I can download and see if it helps. It looks really good and I'm jealous of everyone else that it works for :) |
| ||
| I second Rob's last request about objects casting/receiving shadows, this is important for realism if you are using lightbulb meshes. |
| ||
| BUG: Using pudding's B3D plugin to export a model with 2 texture layers, the entire model was transparent (as if alpha 0.5) on import. Quite alarming... is this because you are hardcoding the texture slot for the lightmap? texture slot 0 holds a base texture texture slot 1 holds a detail map |
| ||
| I'll take a look at that tomorrow :) A list of recent additions: - User configurable lightmap layer! (Needs restart) - User configurable lightmap blend! (Needs restart) - Mesh lighting properties, that can override the material settings. Ie. what Rob asked for, except the hide model thingie :) - A few bugs have been ironed out. Getting closer... |
| ||
| Excellent :) But I still see no 'buy' button... intriguing ;) |
| ||
| Fredborg - just wanted to point you at this if you haven't seen it already: http://www.blitzbasic.com/Community/posts.php?topic=27579 |
| ||
| Ok, I'll add a preference so that you may choose which method to use. |
| ||
| - Undo Paint is in! (only 10 levels of undo for this, as it takes up a bunch of memory) - 'Render Selected' is in as well, 'Render Volume' will have to wait a bit! - 5-10% speed increase when rendering some scenes. - Rendering support for texture scale, position and rotation is in! As seen here:  Release within a week! |
| ||
| I support Rob's feature request, a 'buy' button! :) Awsome job, Fredborg. |
| ||
| very very nice. I'll buy this asap. sort-of-bug: if you open the render.. window, you can still move the selected object in the background. |
| ||
Here's one for Mustang :) Render time: 10 secs on a P4-2.2GHz. Release within one week! |
| ||
| I load up the parking lot scene, delete the lightmap, make a new lightmap (of any size) and render. It shows a progress bar for a second then does nothing. the above image is niiiiiice. |
| ||
| You have to apply the new lightmap to the materials. You can just resize the default one, instead of creating a new one. I really need to get that 'Getting started' tutorial written :) |
| ||
| ahhhhhhh. ta. |
| ||
| If you paint on one surface in the corner, or on an edge where you notice artefacts, is there a chance it might 'overlap' onto another surface? Or is there absolutely no chance of that happening? |
| ||
| Not sure I get the question totally, but here's how it works: - Angular Falloff Checking this will make the intensity of the brush falloff at angular surface change. This means you can paint a floor where it meets a wall, and not affect the wall at the same time. Unchecking this the brush will only consider the distance, and ignore angle differences completely. - Affect All Models Checking this will allow you to paint continuosly over any number of models at once. Unchecking it, will allow you to ie. paint the legs of a chair, and not paint the floor (if they are two seperate models). Gile[s] does not consider surfaces of the same model (in the Blitz sense) to be different entities, but if this is needed I can easily implement it. So if I understand your question you need to disable 'Angular Falloff' and enable 'Affect all models', but I'm still not sure I did :) Or if the question was whether there might be a flaw in the paint system, that would cause other locations than the one you are painting to, to receive paint. Then there might be a very tiny chance of that, but only due to texture filtering if the lightmap is packed very tightly (ie. it's really too small). |
| ||
| I have a concern about texture resolution. I have a 20,000 poly level which is huge. One 256x256 texture will not cut it. One 1024x1024 texture might cut it, but it will stall my graphics card to a crawl. 2048x would look lovely... but my card would run 1fps! Four 512x512 textures would give great quality and still work fine on my card. Does gile[s] generate multiple lightmap textures like common lightmappers? - for example the quake3 tools do this. |
| ||
| Here's one for Mustang :) Oooh... cool! Does gile[s] generate multiple lightmap textures like common lightmappers? I'd like to know this as well... at work we have custom built map generator tool which is REALLY handy as you can either specifyi "max map size" or "texel resolution". So if I say "I want only one 1024*1024 map" it does that and squeezes all my lightmap polygons to that, leaving texel/meter(unit) resolution what comes out of it. And if I say "I want 64 texels/meter(unit)" resolution for my level it makes as many maps as needed, using max map resolution constraint value. Handy, eh? Can gile[s] do that? Have you noticed Mark's Modulate2X test? Giles[s] will have that, right? |
| ||
| Oooh ooh, I have a question! Why did you name it something that invokes the image of a gay British guy? :-) |
| ||
| Rob + Mustang: Currently gile[s] generates the lightmaps you tell it to generate. But if there is a great demand for it to do some automatic, slicing of lightmaps it can be done (with some work). The reason I did it like this was, that I didn't want it to generate multiple surfaces from a single surface, as this would slow down rendering in the users game or application. gile[s] will have the modulate blends, the same day they are included in Blitz. sswift: Just like gay British guys, gile[s] is your friend ;) |
| ||
| Perhaps you can spread it across different entities. Am I right in saying you export it as you find it? ie not one huge fused lump. For example, an average level will probably have 200 seperate entities - corridors, piping, and so forth, so there should be ample free surfaces to do this without having to resort to any surface manipulation (which I'd rather you didn't)... And if people can't provide their levels sufficiently chopped up then it's their hard luck - might be better for you and us. Alternatively you could add simple batch processing where it will load a list of giles files, lightmap with your last settings and save them out again under the same name. |
| ||
| Rob + Mustang: Currently gile[s] generates the lightmaps you tell it to generate. But if there is a great demand for it to do some automatic, slicing of lightmaps it can be done (with some work). The reason I did it like this was, that I didn't want it to generate multiple surfaces from a single surface, as this would slow down rendering in the users game or application. Ok... I can understand that, but... Can I at least set the texel/meter(unit) resolution for rendering or am I stuck just choosing the (combined) lightmap size? Setting the resolution is a must feature even if it might waste some space from the lighmap if it has to use bigger one to be able to put all polys on it (using the texel/meter(unit) resolution set)... here's an example: Room (level), with separate floor, ceiling, walls and staircase (for culling), ie 7 objects. Fine. Now I make lightmaps for this room, for every object, and as you can see they really are one combined object although they are not... so just using 512*512 lightmap equally for every object would create vastly different texel/meter(unit) resolutions per object because they probably have different number of polygons and polygon sizes... end result would be that adjacent walls might look really horrible because the other one has twice as much resolution on its lightmap for example. Being able to set the resolution cures this, but might waste lightmap space... if gile[s] could generate maps as needed, this might reduce the wastage, but would generate more lightmaps (more than one per object). Anyways, I think it would be important to have all these options available. |
| ||
| I do believe it's actually *essential* to be able to have multiple lightmaps on a level. I've been testing gile[s] on some pretty big 20k poly levels and none of the lightmap options are capable of filling it. Ideally, I'd just like to specify a texel resolution and have gile[s] pump out the lightmaps with a maximum size per lightmap. Please don't resort to changing surfaces - you don't need to, just tell your users to ensure there are enough seperate entities... and if the final lightmap only goes over by a few pixels, you can just generate a tiny lightmap on the end. At the moment the only solution I would have is to break my level into four pieces and lightmap+export each seperately. I know this is more work and if it adds 5 euros to the price, then I will pay 5 more euros for a quality product! |
| ||
| Ok, I understand what you are saying, and I'll look into it. But here is how gile[s] work: Lightmaps are linked to materials (or brushes) NOT to model geometry. A lightmap, can be shared between as many or as few materials as you wish. Each material can use the same lightmap, or use a different one. Each lightmap is optimized by usage...This means that ALL polygons using the same lightmap will use the same texel resolution, therefore in Mustang's room example wall, floor, etc. could be set to use the same lightmap, and thus use the same texel size. The good thing about this approach is that you can easily choose where you want the most detailed lightmaps. I.e. a ceiling might not need a particularily highres lightmap, while the walls and floors would need more detail. So you simply apply a lowres lightmap to the ceiling material, and a highres lightmap to the floor and wall materials. This also means you end up with the exact same number of surfaces, as you had before lightmapping. In Rob's example, there is no need to cut up the models. Simply apply different lightmaps to the different materials. If you click on the lightmap button in the lighting properties of the material, you will be taken to the lighting methods window. Here you may select, or create, a lightmap, adjust it's size, and then apply it to the material by clicking the button on the left just below the selection list. When importing any non-gls files into gile[s], it applies a default lightmap to all materials (except ones with alpha blending/textures or masked textures, in which case it chooses vertex lighting, due to some Blitz3D 'problems'). The lightmaps you have in the 'Lighting Methods Window' shows the exact number and resolution of lightmaps gile[s] generates and exports. No more, no less. gile[s] will NEVER generate more lightmaps than you tell it to! |
| ||
| I think I understand now - you work on a per-material basis? So I can actually have four lightmaps on my level just by creating more? |
| ||
| I think I understand now - you work on a per-material basis? Exactamundo! So I can actually have four lightmaps on my level just by creating more? Absolutely, you can have a hundred if you want to :) Just remember to apply them to the materials, or they will make no difference. |
| ||
| Here is a suggestion: Lightmap Wizard option. This wizard will ask you a few questions and based on those questions, generate n lightmaps for n materials. For example it simply looks at the amount of space a material takes up in the level and assigns the material a new lightmap if it is in danger of using up all the lightmap space. This is exactly what we need. |
| ||
| It should be a simple task for you to do I think :) |
| ||
| That would be a good solution! One more for the list :) |
| ||
| Thanks :) |
| ||
| Ideally, I'd just like to specify a texel resolution and have gile[s] pump out the lightmaps with a maximum size per lightmap. Yes, this is what I meant...! Lightmaps are linked to materials (or brushes) NOT to model geometry. Duh... and here I have tried SO hard to minimize the amount of surfaces... so my walls and ceilings etc all use the same material (BIIIG texturemap where I have all the bits)! :/ ...But I guess I can duplicate that "AllInOne" material by making multiple copies of the material in LW, like AllInOne_wall, AllInOne_ceiling, AllInOne_floor etc and assign these "intelligently" to the different parts of the level chunks. But I think that I still need some sort of mechanism (inputbox...) to set the actual texel/meter(unit) resolution for each material when I import my level in? |
| ||
| I've just fixed the last bug, that was bugging me :) So now I'll start looking into the Lightmap Wizard thing! I'll try to incorporate all your demands/suggestions :) |
| ||
| Can you start a new thread (maybe with highlights of this one) for Gile[s] cos this one is starting to take a lifetime to load? :) |
| ||
| Well, I wouldn't want to crowd the forum :) A quick update: - LWO importing is now in! Hoooray, and thanks to Lee! - gile[s] v1.0 will be available for purchase on Monday, December 1st! Here is a screenshot of a Lightwave model, where you can see just how effeciently gile[s] packs lightmaps!  Have a great weekend! |
| ||
| Nice! I look forward to this. I hope there's a slightly discounted price for Blitzers? :) |
| ||
| One word: YIKES! thats some neat packing you've got going there... I will definately buy this package.. but what will it cost? |
| ||
| Hehe :) There is no discount for Blitzers, but if you buy before January 1st, 2004, you will get it at the special introduction price of just 33.33€ (euro), that's 17% off the normal price of 39.95€ (euro)! |
| ||
| Desperately need money for christmas? :p |
| ||
| Naah, just figured it was the nicest way to go about giving blitzers a price cut :) And I need money constantly ;) |
| ||
| I've been following this for a while now... ... yes FreddyB, your app will take over the world. ... we will all stand on line to license it without any resistance at all. ... and we will love it, and endear it to ourselves. ... and we will be happy. Seriously, this is really your crowning acheivement Fredborg... and some really insightfull input from the rest of the 'team' here... this will be a definite must have. Congrats on all the hard work coming to fruition. --Mike |
   |