RE: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson writes: Norman Vine said: Jim Wilson writes: As far as the reason the existing alpha-blend code doesn't work may be related to an update in 1.8.4 that was described in ChangeLog as smaller and cleaner scene graphs. That's just a WAG, but it seems that this function would be better accomplished through an API rather than writing directly back to scenegraph memory from SimGear anyway (I find it mildly irritating that you can even do that :-/). My guess is that you aren't following the rules :-) http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html You might be right. From the above link, it says: If lighting is enabled, then the ambient and diffuse reflectance coefficients of the material should correspond to the translucency of the object. So does this mean that when using the plib API it is necessary to set alpha in both the ambient _and_ diffuse state colors? I think I tried that but... ..for some reason I was seeing some bogus numbers ( 1.0 colors) come up for ambient when dumping the ssgLeaf objects concerned. Maybe finding the source of that problem will fix things. Hmm ... I was alluding render ordering. Note it could be that the 'optimization' code in ssgBranch.cxx is doing things 'behind your back' after loading that invalidates any assumptions about the render order being the inverse of the loading order. not that you are necessarily making this assumption you are familiar with this http://www.sjbaker.org/steve/omniv/alpha_sorting.html Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Norman Vine said: Jim Wilson writes: Norman Vine said: Jim Wilson writes: As far as the reason the existing alpha-blend code doesn't work may be related to an update in 1.8.4 that was described in ChangeLog as smaller and cleaner scene graphs. That's just a WAG, but it seems that this function would be better accomplished through an API rather than writing directly back to scenegraph memory from SimGear anyway (I find it mildly irritating that you can even do that :-/). My guess is that you aren't following the rules :-) http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html You might be right. From the above link, it says: If lighting is enabled, then the ambient and diffuse reflectance coefficients of the material should correspond to the translucency of the object. So does this mean that when using the plib API it is necessary to set alpha in both the ambient _and_ diffuse state colors? I think I tried that but... ..for some reason I was seeing some bogus numbers ( 1.0 colors) come up for ambient when dumping the ssgLeaf objects concerned. Maybe finding the source of that problem will fix things. Hmm ... I was alluding render ordering. Note it could be that the 'optimization' code in ssgBranch.cxx is doing things 'behind your back' after loading that invalidates any assumptions about the render order being the inverse of the loading order. not that you are necessarily making this assumption I don't think that is it. I can set alpha values (by editing the ac3d file) in the test object and it will show as translucency, but the animation code will not manipulate that translucency as it once did. It is as if whatever the alpha is set to at load time, that is where it stays. Note that earlier in this thread it was mentioned that the hack that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) you are familiar with this http://www.sjbaker.org/steve/omniv/alpha_sorting.html Yeah, I think so, but a while back. As you know this has been a regular topic around here. Thanks, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson a écrit : Note that earlier in this thread it was mentioned that the hack that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) Jim, there is no black magic behind this hack that is not one. We found when implementing display lists, that we couldn't manipulate state anymore. So, for certain animation, we just returned back to immediate rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in model.cxx that is doing just that. When a Blend animation is detected, the makeDList function is not called for the animation branch. It is just valid plib usage. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Frederic Bouvier said: Jim Wilson a écrit : Note that earlier in this thread it was mentioned that the hack that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) Jim, there is no black magic behind this hack that is not one. We found when implementing display lists, that we couldn't manipulate state anymore. So, for certain animation, we just returned back to immediate rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in model.cxx that is doing just that. When a Blend animation is detected, the makeDList function is not called for the animation branch. It is just valid plib usage. Do you know the answer to my question? I never suggested it was black magic. It just is not the right way to do it. The hack I'm refering to is color[3] = _blend; in SimGear, where color[3] is a pointer to a property of a plib class (not even in the same library package!). It is inevitable that that kind of thing will lead to breakage...or at least that's been my experience. Dlist doesn't seem to be the issue here, as I mentioned before, writing GL_EMISSIVE works. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
