First of all, a big thanks to Tim - Akenine-Moller &Co. is indeed quite an
interesting read, and in addition to gaining a better understanding, I've so
far experimented successfully with a heightfield for parallax and normal
mapping and a simple irrandiance map instead of the ambient term in lig
Hi all,
Thanks for the feedback, and especially thanks to James for the offer!
I think your request for POC code is very reasonable, so let me get
back to you on that when I have some (although a combobox is already
almost there, as it is basically just a menu with a changing header).
Obviously, i
On 24 Jul 2012, at 13:22, stefan riemens wrote:
> Thanks for the feedback, and especially thanks to James for the offer!
> I think your request for POC code is very reasonable, so let me get
> back to you on that when I have some (although a combobox is already
> almost there, as it is basically
Am 2012-07-24 15:43, schrieb James Turner:
> Oh, I remembered the other 'difficult' widget - the scrolling lists and
> (related) multi-line text. My feeling was that osgText was going to
> handle multi-line text fairly badly, and this might be an issue. We
> don't have many multi-line text widgets,
On 24 Jul 2012, at 16:45, Thomas Geymayer wrote:
> I have just experimented a bit with osgText and multi-line text. So far
> I didn't notice any problems.
My concern was about calculating sane vertical heights allowing for line-wrap,
but that appears to work, based on your demo below!
> But us
On Tue, 24 Jul 2012 07:02:44 +, Renk wrote in message
:
> First of all, a big thanks to Tim - Akenine-Moller &Co. is indeed
> quite an interesting read, and in addition to gaining a better
> understanding, I've so far experimented successfully with a
> heightfield for parallax and normal mapp
Am 2012-07-24 19:35, schrieb James Turner:
> Thomas, one issue I can guess at (though PLIB is also really bad at
> it, and osgWidget is not much better!) - text selection. Do you think
> you'd be able to handle a blinking insertion point and a standard
> draggable text selection area in this approa
> Somewhat inversely, I'm also wondering if a simple texture1D() lookup might
> not be faster than evaluating the light function e / pow((1.0 + a * exp(-b *
> (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet.
That depends a lot on the GPU, and how coherent the texture
coordinates are across
Hi Thomas, Hi James
This looks promising in a technical/coding perspective of having this and that
common GUI feature available also for flightgear. But for me personally one of
the big problems of the FlightGear GUI is that it is "inside" the only and one
main window. There is no possibility t
On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes wrote:
>> Somewhat inversely, I'm also wondering if a simple texture1D() lookup might
>> not be faster than evaluating the light function e / pow((1.0 + a * exp(-b *
>> (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet.
>
> That depends a lot on
10 matches
Mail list logo