 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
ok, chaps - i'm about to unleash my long-awaited debut map - Bastion of the Underworld - but as if to spite me, tyrlite has decided it suddenly doesn't like me anymore and refuses to light my map. here's the important bits of the log:
=========================================== ** Executing... ** Command: C:\Editing\Quake\tools\BENGT_~1\TREEQB~1.EXE ** Parameters: "c:\editing\quake\maps\bastion3.map" TreeQBSP v1.95 -- Modified by Bengt Jardrup Input file: c:\editing\quake\maps\bastion3.map Output file: c:\editing\quake\maps\bastion3.bsp ---- LoadMapFile ---- ----+----+ Title: "Bastion of the Underworld" 34644 faces 5748 brushes 737 entities 74 unique texnames 606 texinfo 4 texture frames added Building hulls sequentially... Processing hull 0... ---- Brush_LoadEntity ---- ----+----+ 5290 brushes ---- CSGFaces ---- ----+----+ 31809 brushfaces 24830 csgfaces 22375 mergedfaces ---- SolidBSP ---- 28762 split nodes 12889 solid leafs 15165 empty leafs 709 water leafs 53805 leaffaces 48311 nodefaces ---- FillOutside ---- 4565 outleafs ---- MergeAll ---- 20143 mergefaces ---- SolidBSP ---- ----+----+ 12247 split nodes 6138 solid leafs 5841 empty leafs 269 water leafs 31831 leaffaces 25388 nodefaces ---- Portalize ---- 6110 vis leafs 19624 vis portals ---- Tjunc ---- 26792 world edges 91489 edge points 19883 edges added by tjunctions 0 faces added by tjunctions ---- MakeFaceEdges ---- ----+----+ ---- GrowRegions ---- Processing hull 1... ----+----+ ----+----+ Processing hull 2... --\ *** WARNING 08: Point (2784 288 -448) off plane by 5.5 *** WARNING 08: Point (2880 352 -448) off plane by 5.76 *** WARNING 08: Point (2880 352 -232) off plane by 5.76 *** WARNING 08: Point (2784 288 -232) off plane by 5.5 ----+----+ ----+----+ ---- WriteBSPFile ---- 9286 planes 185720 35774 vertexes 429288 14125 nodes 339000 606 texinfo 24240 27847 faces 556940 29655 clipnodes 237240 7559 leafs 211652 34463 marksurfaces 68926 129983 surfedges 519932 65861 edges 263444 78 textures 971076 lightdata 0 visdata 0 entdata 72388 10 warnings Elapsed time : 5:02 Peak memory used : 33.4 MB ** Executing... ** Command: C:\Editing\Quake\tools\BENGT_~1\RVis224.exe ** Parameters: -fast "c:\editing\quake\maps\bastion3.bsp" ---- Vis 2.24 ---- Modified by Bengt Jardrup File: c:\editing\quake\maps\bastion3.bsp 6110 portalleafs 19624 numportals State file out of date, will be overwritten fastvis = true average leafs visible: 1387 max leafs visible: 4358 near (800 2176 1056) visdatasize: 1556 kb compressed from 4558 kb Elapsed time : 2:12 ** Executing... ** Command: C:\Editing\Quake\tools\tyrlite\BEN_TY~1.EXE ** Parameters: -lit -nocount "c:\editing\quake\maps\bastion3.bsp" ----- TyrLite v0.94 ----- colored output format: lit BSP is version 29 737 entities read, 406 are lights. Lighting Completed. lightdatasize: 830341 0 switchable light styles Writing BSP version 29 ************ ERROR ************ File read failure ======================================== does tyrlite have a problem with large maps? - it's at nearly 6000 brushes at the moment. bear in mind this has only just started happening, and the only notable thing i have done since it worked fine is add a few brushes here and there - nothing unusual. also, the bsp will become corrupt or something if tyrlite tries to light it, but if i do just a bsp+vis, without lite, the map loads fine in quake, (although obviously fullbright). tyrlite copes fine when i compile just sections of the map, which leads me to believe it's an issue with the size of the full map. any help is massively appreciated. -kinn it is sadly not possible to alter the sprite image scale in the standard engines, but most custom engines support the ".scale" field on sprites, which does exactly what you require.
TyrLite 0.94 cannot handle the large fastvis data size (1.5 MB)that my RVis produces. Try updating to the latest 0.95 from http://www.planetquake.com/tyrann , I believe its vis/light capacity is raised.
Also, the fullvis data size will most likely shrink, but I can't see any reason not to update to 0.95 anyway. Hmm, after checking the 0.95 source I see that its vis capacity is still only 1.5 MB so it probably won't help. Maybe you'll have to use my Light tool during testing (fastvis) and TyrLite for the final (fullvis). My Light has not practical limit for vis data. The fullvis will probably take a while thanks aguirre, that has solved the problem. i am running light before vis now. the reason i am still using tyrlite 0.94 is because i modified the source code slightly to get better results from "delay 2" lights - i simply altered the attenuation formula so that it doesn't blow up to fullbright at the source. (in my version the light intensity at the source is now equal to the "light" value). i cannot open the tyrlite 0.95 source in VC++, so i am stuck with 0.94 at the moment. for those interested, i altered the "delay 2" attenuation formula by changing the following line in the scaledLight function:
(original tyrlite): light->light / ((tmp * tmp) / 16384); (kinn version): light->light / (((tmp + 128) * (tmp + 128)) / 16384); I've been plagued by a "too many lightstyles on a face" warning, although the area in question contains only 3 switchable lights, and no other lightstyles are present. what exactly is the lightstyles limit? i thought it was 4?
there's another, slightly more hacky way to get a higher resolution on sprites. Make a normal sprite at 1:1 scale that is the size you want the final sprite, in regular quake format. Then make
The lightstyle limit is 4 but the code in the light utils has always been a bit overcautious since it checks first if the lightstyles are too many, then if this style actually hits the face.
In TyrLite, there are some changes that should reduce this behaviour but it's still not quite right. I've made some additional changes in my Light tool that hopefully should fix the problem. Also, note that switchable lights also have styles. Disregard last sentence. You could try running my Light to see if the same # warnings are printed.
Xen - hehe, glad someone remembered it. here's a sneaky peek at the Bastion in its current state:
http://photopile.com/photos/sloochyslooch/auctions/112129.jpg http://photopile.com/photos/sloochyslooch/auctions/112130.jpg http://photopile.com/photos/sloochyslooch/auctions/112131.jpg http://photopile.com/photos/sloochyslooch/auctions/112132.jpg http://photopile.com/photos/sloochyslooch/auctions/112133.jpg Hopefully not too long now :) aguirre, i'd like to use your light proggy - would you consider adding my "-kinn" attenuation formula as an option? i'm a bit reluctant to move on from my "hacked" version of tyr 0.94, simply because no other program does the same type of attenuation.
I've completed the beta of my first full scale Quake1 map today, and, and, you make me want to go back to the drawingboard (or get out the rest of that bottle of Southern Comfort and simmer in my own chaote) That brushwork is really good.
ok, i've reposted in the screenshots thread, along with two more pictures :).
necros: yup, ogres et al are present and accounted for, joining a comprehensive bestiary of new and old monsters. lol @ headthump - don't be so hard on yourself :) I've actually also thought of the intense local light effect of the inverse attenuation modes delay 1/2. In my Light there is already some programmatic flexibility for the attenuation formulae, mostly due to my emulation modes (IKLite etc).
I don't think your variant can be achieved with existing logic, so some modification must be done. I'm just wondering how I can add this without just adding a -kinn option. E.g. have you also modified the delay 1 (1/x) lights? They will also get very intense close to the light. Maybe it should be added in the form of new delay modes, e.g. delay 5 would be a modified delay 2 variant? I can see that you might object to this solution although it appears rather logical, after all this is a new attenuation formula. If I add it in the form of an option, what name would you suggest and should it also affect delay 1 lights similarly? Thx Preach & kinn
Do you know the naming convention for texture replacements? I've tried the actual texture name & the format used by DarkPlaces for model texture replacements but neither work. I'm using DP (& fitzquake altho I don't expect it to implement this). Another delay 2 attenuation variant is to cap the formula at the light intensity value, i.e. use the standard 1/(x*x) but no more than 1. This will conform more to the existing delay 2 light distribution, but will weaken the halo around the light.
The advantage is that light intensities don't need to be scaled so much just to get rid of the intense halo. The obvious disadvantage is that the lights in kinn's map are already adapted to the higher attenuation. I just checked how this capped variant looks and it's not bad. Kinn, have you considered this? Does anyone else have an opinion of this issue? For darkplaces, to replace the frames of s_explod.spr you'd need to call the textures s_explode_0.tga, s_explode_1.tga and so on. The numbers correspond to the frame in the sprite you wish to replace, so if it's a simple, single framed sprite, you'd only need to stick a _0 after the name.
That's the first thing I tried & it didn't work. I put them in the progs directory..perhaps I should try textures.
I haven't used the sprite options in Dark Places, but my texture replacement file structure looks like this Quake ---> HeadThump ----> Textures. If you are using Quake 3 BSP format, of course you will need to add the name of the texture file you used in editor below the texture file, like this Quake ---> HeadThump ----> Textures ---> EvilLair8. Hope that helps.
thanks, aguirre. firstly, you mentioned a "capped" option - i probably wouldn't use this option much, as it would still leave a halo of constant brightness around the light, which could look unnatural.
the problem with using my atten. method for a new delay value, eg. delay 5, is that I would have to go back and change the delay field for all existing lights in my map - possible but not entirely desirable, unless there's a search/replace function in Hammer, I dunno. i don't really mind too much how you want to support this - either "delay 5", or "-kinn", it's all good :) of course it would be logical to do a similar thing with the delay 1 lights, as well. if you do it as an option "-kinn" would be awesome, but of course you're free to choose whatever name you feel is best :) again, many thanks for this :) =============================================== glassman - for sprite textures in DP, you must name them like s_explod.spr_0.tga, rather than just s_explod_0.tga, i.e. you need the ".spr" extension before the "_0.tga". keep them in the same directory as the sprites and it should be fine. I suggested the cap variant as I noticed that your new attenuation will completely change lighting in a map, which will make it very hard for others to try it out.
It might also be a reason why some found the lighting in your map washed out, this might be a result of the high attenuation scheme. With the capped variant, you still have the normal light distribution of a delay 2 light, but the halo is greatly reduced. I understand that my delay 5 suggestion is a problem if you can't automate the replace process in or off the map editor. In QuArK (which I'm using), such replacing can be very quick and simple. Please check if there's such a way in Hammer, you might use it for other stuff later. Another way is to just use a normal text editor and change the map file but I'm unsure if you can import it back into the rmf format. Maybe you or another Hammer user know? I'm just trying to make new tool features as generic and flexible as possible and also make them fit together. Adding a delay 5 for your attenuation mode seems like the structured way of doing it. But since you're probably the first (and possibly the only) one to make use of it, it feels important that it's reasonably simple for you. There's also the time frame issue, I'm just about to release a new version of Light and it's a bit late for changes. How far off is your release? Finally, I'd like the zipped map+wad and your modified TyrLite.exe to test the new light feature, since there are no existing maps prepared for it. Is that possible?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |