Author Topic: Wikipedia needs a better FSO pic.  (Read 21139 times)

0 Members and 1 Guest are viewing this topic.

Offline Trivial Psychic

  • 212
  • Snoop Junkie
Re: Wikipedia needs a better FSO pic.
Too bad we can't create our own multi-layered image format to combine the main/transparent map, glowmap, and shine/env, all in one image, and use DDS type compression capabilities.  Granted, it would make for one massive file, and we'd probably need out own editor program to create them, but it would reduce the number of render passes.  Since some people feel like 8-bit is sufficient for glowmaps, while others prefer to keep the full color ranges available, there would need to be more than one format.  72-bit for the 8-bit glowmap, and 84-bit for the version with 24-bit glowmaps.  Granted, if/when we get normal maps enabled, we'd probably want to have a format for that later, so we'd need another 24-bit for that, so that'd make 98-bit for the 8-bit glowmap and 108-bit for the 24-bit glowmap.  Too bad it can't be done right?
The Trivial Psychic Strikes Again!

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Wikipedia needs a better FSO pic.
I think that is exactly what Bobboau is working on implementing in the future?

 

Offline StratComm

  • The POFressor
  • 212
  • Cameron Crazy
    • http://www.geocities.com/cek_83/index.html
Re: Wikipedia needs a better FSO pic.
I'm still intending to retake the cover-in-motion shot with the beam impact fix as soon as I have a chance.  So the debate isn't quite over yet.
who needs a signature? ;)
It's not much of an excuse for a website, but my stuff can be found here

"Holding the last thread on a page comes with an inherent danger, especially when you are edit-happy with your posts.  For you can easily continue editing in points without ever noticing that someone else could have refuted them." ~Me, on my posting behavior

Last edited by StratComm on 08-23-2027 at 08:34 PM

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Wikipedia needs a better FSO pic.
Render passes are based on the operation that's being done, rather than the number of files being used. You could have all the channels in one file, or the all the channels in different files, you'd still need just as many passes.

Bobb's material system will let you do what TP is saying though (while reducing render passes).
-C