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
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,
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
On Tue, 24 Jul 2012 07:02:44 +, Renk wrote in message
e495a106ff5f31448739e79d34138c19196d3...@mbs1.ad.jyu.fi:
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
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 approach?
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 a
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 to
On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes chr...@ijw.co.nz 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
10 matches
Mail list logo