I remember looking at the code for the baking process, it looked like it was made so that the description field could be used to designate what each channel means by using single char markers. Thinking this could be the best way to provide extra clues for the client to use for describing a multi-channel texture. As some of you may know, I had experimented with parallax shaders almost a year ago. The markers are what had spurred me on in hope that it would be possible eventually.
It would be pretty cool if I could mark a channel as a heightmap. http://i56.tinypic.com/ao57uw.jpg Imagine this being possible for everyday use. [Oh and older computers wouldn't need to be left out either. I developed a weaker version of my original parallax shader on the Radeon X850. (That is one ol' graphics card)] - Nexii On Mon, Jan 10, 2011 at 9:18 PM, Joshua Bell <j...@lindenlab.com> wrote: > On Mon, Jan 10, 2011 at 11:47 AM, Ricky <kf6...@gmail.com> wrote: > >> Question: what, if anything, is the 5th channel currently used for? >> > > Bump maps in baked textures. IIRC, only the avatar pipeline > produces/consumes that channel. Also, IIRC, the logic is entirely > client-side at the moment. > > >> Could it be used for normal maps if it is currently unused? >> If so, then we could do this entirely clientside, assuming 5 channel >> textures can be uploaded. Of course there would still need to be a >> way to disable the alpha channel during upload while preserving the >> normal map channel. >> > > That would technically be possible. The asset system does do verification > and modification of various asset types on upload (including textures), but > - again, technically - this would probably work, possibly requiring some > minor changes to the asset verifier. > > However... > > The biggest challenge is the lack of support for multiple channels in > JPEG2000-producing/consuming tools. Many tools only work with 3-channel > images, and complain about 4. Combined with the lack of tools for authoring > JPEG2000 images in the first place, I'm not sure you'd want add another 3 > channels to the image for the normal map. It would also mean you couldn't > re-use a normal map with two textures, e.g. to allow color variants on a > base mesh. > > Avoiding two separate texture asset fetches (colors and normals) per face > might be a significant win, but I'd want to see the numbers to prove it > first. > > (For comparison, the 13-channel RAW data used for uploading/downloading > region terrain and parcel data is pretty pesky to work with. Sure, it works > with PhotoShop, and is a technically simple single file backup format, but > putting all of that data into a single image is fragile that you expect > users to edit is not particularly user-friendly.) > > >> Ricky >> Cron Stardust >> >> On Monday, January 10, 2011, Joshua Bell <j...@lindenlab.com> wrote: >> > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth <d...@meadowlakearts.com> >> wrote: >> > >> > Thats a pretty good bit of thinking out loud there, Ponzu.... >> > >> > Personally I'd say thats a "clean" fix for this. However it all depends >> > on how things are stored server-side - if the asset server code >> > automatically assumes that every texture has an alpha channel and >> > supplies a "solid" one for those where the upload doesnt provide one, >> > any benefit of specifying at upload time is moot. >> > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 >> textures and doesn't tinker with the channel data. The bulk of the textures >> in the asset system are 3-channel (RGB). >> > >> > (Excellent question, BTW.) >> > >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
