CaLight is extremely slooooooow
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
Hi everyone!
Im just (and still) lightmapping my new map... CaLight worked 3 hours for now, and its not finished! With "normal" quality... wtf? Why is CaLight so slow? Other GI Lightmappers like Gile[s] are more powerful (transparency, better quality, soft shadowing) and are faster.
Wfr, Sindwiller
Im just (and still) lightmapping my new map... CaLight worked 3 hours for now, and its not finished! With "normal" quality... wtf? Why is CaLight so slow? Other GI Lightmappers like Gile[s] are more powerful (transparency, better quality, soft shadowing) and are faster.
Wfr, Sindwiller
Im Working on:
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
You are referring to http://www.frecle.net/giles/
Hmm never heard of this editor, but looks interesting and looks quite impressive.
I think its faster because someone worked on this editor ONLY, while Carsten provides a complete package all done by himself (excluding some elements like bezier patches and the old editor code that was used to create CaWe)
And i think Carstens Radiosity mapper code is quite old, in compare to this comercial version.
Edit:
I must admit that the result of this mapper is sometimes quite amazing, i wonder if a quality like this is possible with Ca3D
Wonder what Carsten will think of it XD
Hmm never heard of this editor, but looks interesting and looks quite impressive.
I think its faster because someone worked on this editor ONLY, while Carsten provides a complete package all done by himself (excluding some elements like bezier patches and the old editor code that was used to create CaWe)
And i think Carstens Radiosity mapper code is quite old, in compare to this comercial version.
Edit:
I must admit that the result of this mapper is sometimes quite amazing, i wonder if a quality like this is possible with Ca3D
Wonder what Carsten will think of it XD
Last edited by Kai on 2006-04-21, 13:43, edited 1 time in total.
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
I know that this is much work and i never said that Carsten is doing this bad or something like that. I could never program a radiosity lightmapper or even a ray-tracer. For another example: VRad (the lightmapper used in the Source Engine) is also faster than CaLight...I think its faster because someone worked on this editor ONLY, while Carsten provides a complete package all done by himself (excluding some elements like bezier patches and the old editor code that was used to create CaWe)
Wfr, Sindwiller
Im Working on:
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
Indeed the CaLight.exe you use is very old, Carsten spent a lot of time on it in the meantime. It's now double as fast and uses less memory by the factor of 32!
Soon there's a new SDK out including the new CaLight!
Anyway, you should try "fast", I don't really notice the difference and it's much much faster to comile with these settings ^^
Soon there's a new SDK out including the new CaLight!
Anyway, you should try "fast", I don't really notice the difference and it's much much faster to comile with these settings ^^
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
Oh silly me ^^
Even having the latest build i still dont know about their features XD Well thats why im doing all the external gfx stuff while Thrawn really works with Ca3D *g*
Small Hint: Some voices whispered me that the new SDK would be released .. uhm let me think .. uhm .. oh yeah today (evening)
Even having the latest build i still dont know about their features XD Well thats why im doing all the external gfx stuff while Thrawn really works with Ca3D *g*
Small Hint: Some voices whispered me that the new SDK would be released .. uhm let me think .. uhm .. oh yeah today (evening)
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
But i need the ne CaLight because the old one is extremely slow or doesnt work (after 6h of working, still not finished!).Thrawn wrote:Maybe next week
Wfr, Sindwiller
Im Working on:
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
You can't expect radiosity calculation to be all that fast at the best of times. And if I remember right (don't quote me on this) CaLight is very precise, even reflecting light differently off different parts of a texture and so on.
But how much memory do you have? Because if it's thrashing then that could slow things down alot.
But how much memory do you have? Because if it's thrashing then that could slow things down alot.
No-one quite knows why I'm here...
Yes. Yes. Yes. CaLight is inherently slow.
First of all, have you read http://www.ca3d-engine.de/wiki/doku.php ... :compiling ? This is another text that's not quite up-to-date (e.g. the CaLight.cfg file does not exist any more), but explains the basic tool options. Best is however if you run CaLight without options to get a short help message. This message is accurate and up-to-date.
Also note that 6 hours to 3 days are not uncommon with CaLight for good quality lighting (you can make it much faster with the command line options, though).
If you have not run CaPVS before CaLight, please do so - it's crucial for speed! (CaLight also warns you about this if it didn't find any PVS information.)
Second, Razor is of course right about thrashing: If your harddrive LED is permanently on, better stop it...
You can also estimate how long CaLight will approximatly run by looking at the BestUE value in it's output. This number is getting smaller over time, and when the StopUE value is reached (1.0 by default), it will stop.
On Windows, you can also press the SPACE key to prematurely abort as soon as the next interation is complete.
Oh, and while the new version will indeed take 32 times less memory for one of it's major data structures, please don't count on it being faster - the algorithm remains the same.
Comparing CaLight with Giles is imho not possible: First of all, it seems that they're using very high-res lightmaps in relatively small scenes, while lightmaps in Ca3DE must cover entire levels (and thus huge surface areas) and thus must be lower-res as Giles'. Then, the images above look as if some tricks were used, I don't think that they really were created by methods that model physical reality - none of the scenes looks particularly realistic to me.
To sum it up: While CaLight indeed is very slow because it models physical reality with great accuracy, and while (for now) nothing can be done about it, there are several options to make it faster as described above.
Hope that helps.
First of all, have you read http://www.ca3d-engine.de/wiki/doku.php ... :compiling ? This is another text that's not quite up-to-date (e.g. the CaLight.cfg file does not exist any more), but explains the basic tool options. Best is however if you run CaLight without options to get a short help message. This message is accurate and up-to-date.
Also note that 6 hours to 3 days are not uncommon with CaLight for good quality lighting (you can make it much faster with the command line options, though).
If you have not run CaPVS before CaLight, please do so - it's crucial for speed! (CaLight also warns you about this if it didn't find any PVS information.)
Second, Razor is of course right about thrashing: If your harddrive LED is permanently on, better stop it...
You can also estimate how long CaLight will approximatly run by looking at the BestUE value in it's output. This number is getting smaller over time, and when the StopUE value is reached (1.0 by default), it will stop.
On Windows, you can also press the SPACE key to prematurely abort as soon as the next interation is complete.
Oh, and while the new version will indeed take 32 times less memory for one of it's major data structures, please don't count on it being faster - the algorithm remains the same.
Comparing CaLight with Giles is imho not possible: First of all, it seems that they're using very high-res lightmaps in relatively small scenes, while lightmaps in Ca3DE must cover entire levels (and thus huge surface areas) and thus must be lower-res as Giles'. Then, the images above look as if some tricks were used, I don't think that they really were created by methods that model physical reality - none of the scenes looks particularly realistic to me.
To sum it up: While CaLight indeed is very slow because it models physical reality with great accuracy, and while (for now) nothing can be done about it, there are several options to make it faster as described above.
Hope that helps.
Best regards,
Carsten
Carsten
-
- Posts:108
- Joined:2006-04-14, 21:11
- Location:Zürich, Switzerland
Well, im using Thrawn's GUI Tool because i dont like cmd.exe... i will try some paramaters to look how high can i speed things up.Also note that 6 hours to 3 days are not uncommon with CaLight for good quality lighting (you can make it much faster with the command line options, though).
If you have not run CaPVS before CaLight, please do so - it's crucial for speed! (CaLight also warns you about this if it didn't find any PVS information.)
Note that those overblending "tricks" are because of the glas. Gile[s] is accurate and makes physics correct lightmaps. Not only that the simple model is physical correct. Reflective surfaces are reflecting light (diffuse surfaces are doing this too, but not so strong like reflective surfaces), transparent surfaces spread light.Comparing CaLight with Giles is imho not possible: First of all, it seems that they're using very high-res lightmaps in relatively small scenes, while lightmaps in Ca3DE must cover entire levels (and thus huge surface areas) and thus must be lower-res as Giles'. Then, the images above look as if some tricks were used, I don't think that they really were created by methods that model physical reality - none of the scenes looks particularly realistic to me.
Yes, this helps much .Hope that helps.
Wfr, Sindwiller
Im Working on:
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
- Some Linux Bash-Scripts for installing stuff. Dont ask further questions, because i can't explain that more simple ^^
If you have a look at light_fast.bat (Ca3D-Engine/Tools/MapCompiler, can be opened wih the text editor), the following line is important:Well, im using Thrawn's GUI Tool because i dont like cmd.exe... i will try some paramaters to look how high can i speed things up.
Code: Select all
CaLight_win32_vc60_r Games/%MODNAME%/Worlds/%MAPNAME%.cw -BlockSize 8 -UseBS4DL -NoFullVis -SkipDialog -StopUE 10.0
Who is online
Users browsing this forum: No registered users and 99 guests