Re: [Amelia-development] Irrlicht API Change?

[Karol K. <kk...@gm...>]

On Tue, Nov 18, 2008 at 8:46 PM, Karol Krizka <kk...@gm...> wrote:
> On Tue, Nov 18, 2008 at 8:19 PM, Joao Pequenao <jpp...@lb...> wrote:
>> Hi Karol,
>>
>> Check my last commit. As I wrote in the log:
>>
>> Log Message:
>> -----------
>> - Corrected the reference to geometry meshes, as per Irrlicht API change
>> - Transparent materials are now transparent again
>> - Corrected a strange overlap in the Z-Buffer of transparent objects
>> - Changed the look of some objects, enabled anisotropic filtering on some
>> textures
>> - On CMakeLists.txt the parameter for inclusion of QtWebKit was corrected
>> (as per API changes)
>>
>> The only problem now is really the crashing of renderViewports under Linux.
>> On Windows, things work pretty well already. I feel tempted to release the
>> binaries produced some minutes ago (for Windows) as our alpha.
>>
> I think that the bigwheel is way too transparent, ei I can barely see
> that it's there in parts. But apart from that, I do agree that we can
> release the Windows binaries.
>
> On Linux, the problem seems to be if one does not have Framebuffer
> Object, then there is a problem with grabbing the data of the texture.
> I've already let the Irrlicht developers know about it.
>
Ok, I think this has been resolved. I'm not sure what the problem was,
but I was stepping up Irrlicht revisions to see when the problems
started appearing, and they never appeared even when I reached the
latest revision! I'm guessing something must have gotten corrupted
with my original checkout...

Anyways, there is still one more thing before a release. :P You missed
a few meshes in your last commit. The meshes in ATrack3DNode classes
still use the old API and crash AMELIA when you load an event.

Finally, I've made one commit to the AGeometry class. This is just
some cleanup as I've noticed we were doing some extra unneeded
redrawing in the function and I've found out that we can grab the
texture data in a read-only mode which is supposed to "speed up those
calls.".

--
Cheers,
Karol Krizka

>
>
>> Cheers,
>>
>> Joao
>>
>>
>>
>> Karol Krizka wrote:
>>
>> On Tue, Nov 18, 2008 at 10:10 AM, Joao Pequenao <jpp...@lb...> wrote:
>>
>>
>> Hi Karol,
>>
>> I'm not at my office right now (I'm actually at Pixar this morning).
>> I noticed yesterday the same problem. It actually affects more things too,
>> like the alpha channel of some textures (notice for example the pixel
>> end-caps, which look weird now...)
>> Before, the material characteristics were applied by node, but now it's by
>> material layer. Must change that too...
>>
>>
>>
>> Ah ok, good you know what the problem is. Also I've noticed that the
>> renderViewports code crashes and I've been looking into that.
>>
>>
>>
>> I believe that's the last thing to do before posting binaries.
>>
>> I'll be back to my office by lunch time and implement that immediately.
>>
>>
>>
>> I have to go to classes in a big and in the afternoon I have my long
>> Tuesday lab, but I will be at a computer at around 6:00pm fixing
>> whatever needs to be fixed.
>>
>>
>> Cheers,
>>
>> Joao
>>
>> Karol Krizka wrote:
>>
>>
>> Hi Joao,
>>
>> I'm having some trouble running the latest version of AMELIA when using the
>> latest Irrlicht revision. It keeps crashing at line 881 of AGeometry:
>>            nodeModels->getMaterial ( 0 ).DiffuseColor.set ( 0,180,180,120 );
>>
>> This is because nodeModels is 0. However I managed to fix it by chaning line
>> 874 from
>>        scene::IMesh* TC = Device->getSceneManager()->getMesh (
>> "TC_Barrel01.x" )->getMesh ( 0 );
>> to
>>        scene::IMesh* TC = Device->getSceneManager()->getMesh (
>> "TC_Barrel01.x" );
>>
>> There are a few other lines where you load a mesh and then run getMesh( 0 ),
>> and I had to fix those too. But I don't really know how the meshes work in
>> Irrlicht, so I'm not sure if this is just some API change or some real
>> problem...
>> --
>> Cheers,
>> Karol Krizka
>>
>>
>