Unfortunately, I failed to open that. But according to the image, I think that this is not what I want. If map the image using a Texture object with a binding from alpha to transparency R, G and B everything is fine as long as the image that is set for the texture object has an alpha channel. If it doesn't have an alpha channel, the binding gets changed automatically without warning. The alpha source of the binding gets switched to R.
I think that I have problems with conveying what it is that I want. I will try again. :) What I want to do is to create a material that has these attributes in the "user interface" part: Diffuse colour, ambient colour, specular colour, specular intensity and an image map. This VSL material is then copied over and over for every material in the scene and the attribuites are set according to the model, either when loaded or when a person assigns them. The important thing here is that all of these materials are identical in construction - only the values of the attributes are allowed to change. Now, some materials will have an image map set in the image map attribute some will not. The materials that has no image map must still function, i.e. the prescence of an image map must be tested by the "code" in the vsl material. For materials that do have an image map assigned to the image map attribute of the material the material must test if the image it is currently set to has an alpha channel or not. If it has an alpha channel, these values will be mapped to Surfacs:Transparency with a Texture VSL object. If the image that is currently assigned to the image map property does not have an alpha channel, transparency will not be modified by this material. The thing is that, when the user, or the object loader, assigns an image to the attribute, no changes to the VSL "code" should be done. Just the value of the attribute should have to be changed. The reason for this material is that I want to have a standard material that has all of the features of the game engine I'm making this stuff for. The key thing is to make sure that the materials used doesn't have any features that are not supported by the game engine. When IU have a VSL material that works, the plan is to encapsulate this material in a new material class defined by my plugin. This class would completely restrict modification of the VSL code. Think of how v3materials are used in RS today. I guess that they too are implemented as regular VSL objects, just that the VSL code is hidden from the users and instad a more simple user interface is presented. Does this help, or am I just making stuff even more complicated? ;) Regards, Fredrik Bergholtz On 29/04/06, Matthias Kappenberg <[EMAIL PROTECTED]> wrote:
Something like this? Matthias ----- Original Message ----- Wrom: VZCMHVIBGDADRZFSQH To: <[email protected]> Sent: Saturday, April 29, 2006 1:59 PM Subject: Re: Testing an image for an alpha channel Oh, I think that my description may not have been fully clear. (Bad pun, sorry :) ) I do all this, the thing is that I want to be able to use the same material even if the actual image map has no alpha channel. When I try this, loading an image map with no alpha channel, the bindings get messed up and the red channel will be sent to transparency. This is what I want to avoid. Think of it like a special kind of material, I want to set up a bunch of user editable attributes, one of which is an image map. If this image map contains an alpha channel, that would be sent to transparency, but if it doesn't have an alpha channel, transparency won't be affected by the material. What I want is to make sure that the last three VSL objects in the material shown in the attached image are only evaluated if the image has an alpha channel. Regards, Fredrik Bergholtz On 29/04/06, David Coombes <[EMAIL PROTECTED]> wrote: > Yes, you can do that, but you're thinking about it wrong. What you want to > do is output to the surface transparency the value held in an images Alpha > channel. > > In your Surface Properties shader add a Texture object. > Load your texture with Alpha channel. > Set the output of the texture object (In/Out tab) to Surface:Transparency > In the Bindings tab, click the Edit checkbox and set the bindings so the > Transparency's RG and B channels (destination) are set from the source > image's A channel > > At this point I'll mention I can't actually do this because RS's window is > busted and has been as long as I've known the software. When I click Edit > Binding the Source panel extends to below the bottom of the window and I see > no destination panel. No amount of opening and closing windows and panels > and Ctrl left right shift click and dragging will expose the rest of the > interface for me. The way panels auto scale and such I've always found > awkward as they invariably produce a window far longer than my 768 pixel > height display, and often don't terminate at the bottom of the window > anyway. > > Anyway, what you are doing is selecting a picture that has Red, Green, Blue > and Alpha components, and saying 'For each pixel, take the images Alpha > value and set that as the transparency value of the Red, Green and Blue > colour components of the surface.' You can just as easily create a black and > white image and set the value of surface transparency to the red component > of the image, using it as a mask. > > David Coombes > [EMAIL PROTECTED] > > ... > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Saturday, April 29, 2006 11:56 AM > Subject: VSL: Testing an image for an alpha channel > > > > Hi, is it possible to test for the prescence of an alpha channel in a > > given image map inside a VSL material? > > > > Something like: > > > > Surface properties > > { > > do stuff > > > > if (image has alpha) > > { > > Apply alpha channel of image to surface transparency > > } > > } > > > > I want to use the same structure of the VSL material for all my > > objects to let users simply change the possible parameters that match > > the in-game material properties without having to modify the actual > > VSL code. > > > > Regards, > > Fredrik Bergholtz > > > >
