Irrlicht with cubemap support
-
- Competition winner
- Posts: 523
- Joined: Tue Jan 15, 2013 6:36 pm
Re: Irrlicht with cubemap support
Hardware skinning and custom vertex descriptors for my radiosity lightmaps.
Re: Irrlicht with cubemap support
Why don't you show your hardware skinning and radiosity lightmap code and sample.
I think the guys will adopt it if they fine them easy to port over.
I think the guys will adopt it if they fine them easy to port over.
-
- Competition winner
- Posts: 523
- Joined: Tue Jan 15, 2013 6:36 pm
Re: Irrlicht with cubemap support
There's not really anything to show really the only thing I use for the lightmapping side on Irrlicht is the custom vertex descriptors in shader-pipeline. If I didn't you can't have 2 texture coordinates and tangents at the same time.
Re: Irrlicht with cubemap support
Why did "addTextureCube()" not make it to Irrlicht 1.8.4?
Re: Irrlicht with cubemap support
I think you asked that also for some other feature? The last number means bugfix release. No new features.
Re: Irrlicht with cubemap support
Yeah as hendu said - 1.8 series is on maintenance, we try to keep binary compatibility for that. So basically the only thing going in there are bugfixes which are not breaking that and which also are not likely to mess with any existing application. So for example a fix for wrong colors already wouldn't make it in as people already might rely on those.
Real development is all in Irrlicht svn trunk which will become Irrlicht 1.9 one day (I hope...).
Real development is all in Irrlicht svn trunk which will become Irrlicht 1.9 one day (I hope...).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
Re: Irrlicht with cubemap support
Is there a big TODO on 1.9? Would be interesting that we see a progress thread of the development... (even if we can see most of that reading the svn log)
Re: Irrlicht with cubemap support
Biggest TODO continues to be the ogl-es branch (same as last years...). Changing input device there (we don't like the current solution) and merging with trunk. And a bunch of other stuff as well.
But admittably not working on those tasks currently. I can't code much at all this year due to health reasons. Some Tinnitus I had for years got really bad after new year and I can't sleep or concentrate well since then. Which makes coding hard for me. I still try to keep up with bugreports and fix minor stuff in Irrlicht, but can't do more than that at the moment. Trying to get used to this, but my main fight right now is my day job as I'm really close by now to have to give up programming completely.
But admittably not working on those tasks currently. I can't code much at all this year due to health reasons. Some Tinnitus I had for years got really bad after new year and I can't sleep or concentrate well since then. Which makes coding hard for me. I still try to keep up with bugreports and fix minor stuff in Irrlicht, but can't do more than that at the moment. Trying to get used to this, but my main fight right now is my day job as I'm really close by now to have to give up programming completely.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht with cubemap support
I See. I was also wondering, is there a single proper document that covers all the issues involved
with SVN, TRUNK, PIPELINE, PATCHES, ETC ETC..
I am sort of beginning to understand the patch which seems to be a method for replacing
lines of code in the engine code itself. Now all of this looks interesting, but I couldn't
find anything really descriptive on how to apply a patch, I mean with all the "+"'s and "-"s
I suspect "+" goes in and "-" is deleted, but there are all sorts of other symbols too which
I don't have a clue on. Is the extension of "*.patch" a way to tell some system to automate
the deletion and replacement of lines or is it something else.
Um, what I'm trying to say is there a document that stipulates, step by step, by example of
what one should do to get this patch into the Engine Code before recompiling?
I found a "*.patch" that deals with Cube Maps i.e.
I've dealt many times with this "addTextureCube" command a long time ago when I wrote things in Win32, Opengl and CG.
I would have loved to do the same in Irrlicht..
Now, I understand that once I got this "*.patch" in and recompiled the DLL, it should work, but may mess with
other fundamental and deeper inside the engine resulting in some other programs not running optimally.
It would also cause that I couldn't share any of my code in a way that someone with Standard Irrlicht could compile it.
I've seen a lot of this like X-Effects and IRR-Render which I had to "panel beat" to work with standard Irrlicht.)
Anyhow, I would then attempt to find these "breaks" and try to fix them and if they look cool
they might even somehow find their way into the next major release.
So after all this dreaming and speculating, am I totally wrong?
Is there, somewhere a "comprehensive guide" on how to do all these things?
I am a bit of an Irrlicht noob and used to focus mainly on GPU routines so, er..uh..
with SVN, TRUNK, PIPELINE, PATCHES, ETC ETC..
I am sort of beginning to understand the patch which seems to be a method for replacing
lines of code in the engine code itself. Now all of this looks interesting, but I couldn't
find anything really descriptive on how to apply a patch, I mean with all the "+"'s and "-"s
I suspect "+" goes in and "-" is deleted, but there are all sorts of other symbols too which
I don't have a clue on. Is the extension of "*.patch" a way to tell some system to automate
the deletion and replacement of lines or is it something else.
Um, what I'm trying to say is there a document that stipulates, step by step, by example of
what one should do to get this patch into the Engine Code before recompiling?
I found a "*.patch" that deals with Cube Maps i.e.
Code: Select all
ITexture* cubeMap = Driver->addTextureCube("sky", posXImage, negXImage, posYImage, negYImage, posZImage, negZImage);
I would have loved to do the same in Irrlicht..
Now, I understand that once I got this "*.patch" in and recompiled the DLL, it should work, but may mess with
other fundamental and deeper inside the engine resulting in some other programs not running optimally.
It would also cause that I couldn't share any of my code in a way that someone with Standard Irrlicht could compile it.
I've seen a lot of this like X-Effects and IRR-Render which I had to "panel beat" to work with standard Irrlicht.)
Anyhow, I would then attempt to find these "breaks" and try to fix them and if they look cool
they might even somehow find their way into the next major release.
So after all this dreaming and speculating, am I totally wrong?
Is there, somewhere a "comprehensive guide" on how to do all these things?
I am a bit of an Irrlicht noob and used to focus mainly on GPU routines so, er..uh..
Re: Irrlicht with cubemap support
There is a command-line tool called patch which can do patches automatically (though it also often fails because of different formats and stuff). Some other tools might also be able to work with patch files. Manually - yeah the + are lines to add and - to remove (in one format in another it might use >>> and <<< to show blocks to add and remove). And before it might tell which file and line has to be changed and sometimes it might tell which lines are around it.
Then sometimes people just call it a patch when they mean - they have some change which should be applied in any way to the engine.
Subversion (or short: svn) is the version control system we use. trunk is the main development branch in there (it's generally called trunk in projects - just a common naming scheme which lots of projects use). Branches are copies made at some point in time (usually copies from trunk - it's all a big tree of code when you try to draw it). So we have a branch after reach release and that copy will only receive minor fixes while we continue our work in the trunk (main) branch. Pipeline... no idea - means a lot depending on context.
The optimal way for patches is to post them here: https://sourceforge.net/p/irrlicht/patches/
And add a test so we can check out if it works which will improve the chances of the stuff to get added to the engine at least 10 times (not joking, basically no test - someone else like me has to code it first - which I will basically only do once I need that stuff myself or have spare-time *ineverhavehadsparetimetoburnforthisever*).
Then sometimes people just call it a patch when they mean - they have some change which should be applied in any way to the engine.
Subversion (or short: svn) is the version control system we use. trunk is the main development branch in there (it's generally called trunk in projects - just a common naming scheme which lots of projects use). Branches are copies made at some point in time (usually copies from trunk - it's all a big tree of code when you try to draw it). So we have a branch after reach release and that copy will only receive minor fixes while we continue our work in the trunk (main) branch. Pipeline... no idea - means a lot depending on context.
The optimal way for patches is to post them here: https://sourceforge.net/p/irrlicht/patches/
And add a test so we can check out if it works which will improve the chances of the stuff to get added to the engine at least 10 times (not joking, basically no test - someone else like me has to code it first - which I will basically only do once I need that stuff myself or have spare-time *ineverhavehadsparetimetoburnforthisever*).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht with cubemap support
Wow! Thanks CuteAlien! That's just what I needed.
Re: Irrlicht with cubemap support
Yes, those are the same.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Irrlicht with cubemap support
I'm going to try "patch" the "ITexture.h" file to facilitate the "addTextureCube" function..
Couldn't run the pre-compiled 64 bit example, so maybe I can compile my own 32 bit exe running with a new 32 bit DLL!
i.e. http://irrlicht.sourceforge.net/forum/v ... =2&t=44884
Thanks again, Ill keep you posted..
Couldn't run the pre-compiled 64 bit example, so maybe I can compile my own 32 bit exe running with a new 32 bit DLL!
i.e. http://irrlicht.sourceforge.net/forum/v ... =2&t=44884
Thanks again, Ill keep you posted..
Re: Irrlicht with cubemap support
Sorry to hear that, CuteAlien.
I'm sure you've researched everything, but one cause I remember was TMJ - tight jaw muscles. At least that's an easy one to rule out.
I'm sure you've researched everything, but one cause I remember was TMJ - tight jaw muscles. At least that's an easy one to rule out.