What about Irrlicht? (with feature suggestions)

What about Irrlicht? (with feature suggestions)

Postby MyEmail » 06 Jul 2011, 09:27

So, quick question: Why isn't this project based off of something like Irrlicht? This could no doubt benefit vastly from Irrlicht's codebase, as many of the things you seem to be struggling with are already taken care of. Consider for a second if you where to import Irrlicht, create a sub-class of the BSP node-class to add any additional features your engine requires, and be 100% done with your dungeons rendering code in a week of work?

Here are a few more examples:

    A couple of quick workarounds to the BSP materials to support GLSL shaders, plug them into Irrlicht's material system, and poof you have real-time lighting in your dungeons with bump-mapping, parallax/relief mapping, reflective/refractive water, oozing lava, etc. (might even throw in some wang tiles to keep the redundancy down... hint hint).

    A few tweaks here and there to add event scripting (with Chai or Lua) to the BSP models, and shaaazam you have walls that move when triggered, platforms that raise when characters stand upon them, evil traps that unleash when a player opens a treasure chest, etc.

    A handful of tricks to integrate Bullet physics, and wowzers you have a real-world destructible environment with walls that can be crushed, crates that explode, enemies bodies collapse on death, etc.



That's just a thought--as by basing this off of Irrlicht literally 90% of your code would be done. It would just be a matter of gluing it all together with your game logic code. I have some base Irrlicht code I would be willing to donate if you dev's are interested in making the switch...
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: New look

Postby StefanP.MUC » 06 Jul 2011, 15:13

From the sound of your post I assume you are believing we have written our own render system? That's not true, we are using Ogre. And feature-wise Ogre can do more than Irrlicht.
StefanP.MUC
 

Re: New look

Postby svenskmand » 06 Jul 2011, 15:32

MyEmail {l Wrote}:...might even throw in some wang tiles to keep the redundancy down... hint hint ...

This actually sounds like a nice idea, it would be a nice alternative (and with no performance penalty) to texture splatting. Especially this paper in the wiki page is usefull.
Jamendo.com - The best music store on the net, uses CC licenses.
User avatar
svenskmand
OD Moderator
 
Posts: 1850
Joined: 09 Dec 2009, 00:07
Location: Denmark

Re: New look

Postby oln » 06 Jul 2011, 17:36

StefanP.MUC {l Wrote}:From the sound of your post I assume you are believing we have written our own render system? That's not true, we are using Ogre. And feature-wise Ogre can do more than Irrlicht.

I had the same thought.
Irrlicht may be easier to use than Ogre, (I don't feel like starting a discussion about what's best) but I don't think it's worth making a switch at this stage (Unless there are some very good reasons for making the switch). There are however other areas where I think we should consider changing libraries, especially for threads and possibly networking.
The problem here is rather that none of us know ogre very well, so what we should do is put some questions on the ogre forums, to ask how to best implement/design the various graphics tweaks (e.g the wang tile suggestion). We should also try to switch to the RT shader system in ogre, but the documentation is a bit confusing.

Bullet physics could potentially be used in the future, but there are numerous other areas that need work before that.
Scripting is planned, firstly for player AI and possibly console use, but can probably extended to other areas later. (Not sure what the optimal scripting language(s) and libraryes for this are though.)
User avatar
oln
 
Posts: 1020
Joined: 26 Oct 2010, 22:16
Location: Norway

Re: New look

Postby MyEmail » 07 Jul 2011, 07:57

svenskmand {l Wrote}:
MyEmail {l Wrote}:...might even throw in some wang tiles to keep the redundancy down... hint hint ...

This actually sounds like a nice idea, it would be a nice alternative (and with no performance penalty) to texture splatting. Especially this paper in the wiki page is usefull.

Or you could just do both to further reduce the redundancy--as neither is completely adequate. Do a simple GLSL 4-channel splat, and make each texture a set of wang tiles (it will do miracles for you). And there shouldn't be any real performance penalty, as both are screaming fast compared to the alternatives.

oln {l Wrote}:Irrlicht may be easier to use than Ogre, (I don't feel like starting a discussion about what's best) but I don't think it's worth making a switch at this stage

Its never too late to switch :). As you where mentioning, Ogre is overly-bloated causing it to be confusing. Like I said in my 1st post, literally all you would do is derive from the BSP node class in Irrlicht to replace its default Quake config parser and material management. From there it is easy to add nice graphical effects (bump/relief mapping, etc), and custom stuff specific to your game--all nicely embedded in Quake maps.

Its a matter of adding normal/height maps to the BSP materials, and shoving them into Irrlicht's material system and saying "here, render this with parallax mapping!", and poof its rendered with parallax mapping.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: New look

Postby StefanP.MUC » 07 Jul 2011, 08:54

I'm not sure if I'd further contribute If we switch the engine now.

When I started coding on OD, I was not new to C++, but I was new to Ogre, CEGUI and OIS and SFML. And I really don't have the desire to yet learn another new engine. It would also mean converting all the Ogre overlay stuff (console, textrenderer, e.g.) to Irrlicht. Then we would need to change the GUI code, because we would need to change the CEGUI renderer. And, most importamt I think, the whole FrameListener stuff probably would'nt work in Irrlicht. Next, we would have to change the Input System. Ogre comes with OIS, we would need take care of OIS dependencies by ourself (instead of letting the Ogre team do it for us). All in all, it would mean converting the whole codebase, excluding audio.
StefanP.MUC
 

Re: New look

Postby oln » 07 Jul 2011, 09:47

MyEmail {l Wrote}:Its a matter of adding normal/height maps to the BSP materials, and shoving them into Irrlicht's material system and saying "here, render this with parallax mapping!", and poof its rendered with parallax mapping.

Well, doing this with ogre is not that much different if we switch to the RTshader system in Ogre 1.7. It's just that neither of us have really learned Ogre from the bottom up, so we just have to learn how to use it first.

Even if doing these changes in Irrlicht might be slightly easier, I don't see a good reason to do a full switch, because, as stefan said, it would require rewriting a lot of code. (Not the GUI though, as CEGUI does support Irrlicht.)

Also, I don't think using quake maps would be right, since pretty much everything in the game is dynamic / no static geometry. (Which is again a bit of the problem here, most 3D games have a lot of static geometry, and thus code/engines/documentation is more geared towards this.)
Last edited by svenskmand on 07 Jul 2011, 11:04, edited 1 time in total.
Reason: Misquotation
User avatar
oln
 
Posts: 1020
Joined: 26 Oct 2010, 22:16
Location: Norway

Re: New look

Postby svenskmand » 07 Jul 2011, 11:07

Yes we should NOT switch engine, now that would be suicide. But I do think that the idea with the Wang Tiles is good, it will grant allot of Skorpios wishes to have a more varied look of the game. Also the article I liked to (that is also in the wiki page) is pretty straightforward to implement it from.
Jamendo.com - The best music store on the net, uses CC licenses.
User avatar
svenskmand
OD Moderator
 
Posts: 1850
Joined: 09 Dec 2009, 00:07
Location: Denmark

Re: New look

Postby MyEmail » 07 Jul 2011, 17:41

Ok, well I was kinda implying I would help you guys out to get the basics going (rendering & scripting) but it seems your better off on your own. Best of luck with the project.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: New look

Postby charlie » 07 Jul 2011, 19:13

MyEmail {l Wrote}:Ok, well I was kinda implying I would help you guys out to get the basics going (rendering & scripting) but it seems your better off on your own. Best of luck with the project.


Yes and you also stated that 90% of the project code would be done by switching to Irrlicht, so I'm not sure whether the suggestion was ever worth taking seriously.

I mean, what about the multiplayer/networking side of things? What about GUI logic, what about AI, what about the million-and-one tasks you are omitting in your ridiculously kind-to-Irrlicht or naive assessment of what constitutes "done" when creating a game with as big a scope as OpenDungeons?

Don't get me wrong, I'm sure Irrlicht is good, but you've totally oversimplified the whole thing both in terms of making a transition (that would take ages, unless you can prototypically prove otherwise) and the benefits to the transition (90%...).
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2130
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: New look

Postby Skorpio » 07 Jul 2011, 23:14

So can Wang tiles only be used to break up visible patterns in ground textures or can they help with transitions as well? I was planning to create different dirt or stone textures anyway, but wasn't sure if all tiles had to be exported twice or thrice then, or if the textures/materials could be switched randomly in OD.

The dirt/stone tiles are complete now (at least I hope so). I had to create 46 different dirt walls in order to get all possible combinations. The problem is, they don't fit to the claimed wall set perfectly and there will be gaps. Also the poly count could be a bit high. I'll post some screenshots tomorrow.
User avatar
Skorpio
OD Moderator
 
Posts: 775
Joined: 05 Dec 2009, 18:28

Re: New look

Postby MyEmail » 08 Jul 2011, 08:29

charlie {l Wrote}:
MyEmail {l Wrote}:Ok, well I was kinda implying I would help you guys out to get the basics going (rendering & scripting) but it seems your better off on your own. Best of luck with the project.


Yes and you also stated that 90% of the project code would be done by switching to Irrlicht, so I'm not sure whether the suggestion was ever worth taking seriously.

I mean, what about the multiplayer/networking side of things? What about GUI logic, what about AI, what about the million-and-one tasks you are omitting in your ridiculously kind-to-Irrlicht or naive assessment of what constitutes "done" when creating a game with as big a scope as OpenDungeons?

Don't get me wrong, I'm sure Irrlicht is good, but you've totally oversimplified the whole thing both in terms of making a transition (that would take ages, unless you can prototypically prove otherwise) and the benefits to the transition (90%...).

charlie: I am sorry, but I don't appreciate flaming. As I mentioned in one of my previous posts I was going to help this project out at a minimum of scripting & rendering, but was also debating on GPL'ing a Irrlicht based engine I developed for a failed game called SoulForge (that's that "naive assessment/90% done" thing you are referring too). But I really don't like you, so have a nice day.


svenskmand: I would be happy to help you get a 4-texture splat system up, as well as some cheap (as in rendering-cost kind of "cheap") redundancy-reducing tricks.

Skorpio {l Wrote}:So can Wang tiles only be used to break up visible patterns in ground textures or can they help with transitions as well?

Skorpio: Wang tiles would help with the redundancy. Splatting would be a good solution for the transitions.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: New look

Postby svenskmand » 08 Jul 2011, 10:30

MyEmail, we are very appreciative about your advice, although we are not going to switch engine, but allot of your advices can also be used with ogre. If you want to help out with the wang tiles and texture splatting that would be awesome. In any case I think the project have benefitted from this discussion :)

Skorpio is it just the dirt to stone transitions that takes you 46 tiles? Why is 12 not enough? A top down scrennshot would probably clarify this, when you make it.
Jamendo.com - The best music store on the net, uses CC licenses.
User avatar
svenskmand
OD Moderator
 
Posts: 1850
Joined: 09 Dec 2009, 00:07
Location: Denmark

Re: New look

Postby charlie » 08 Jul 2011, 11:49

MyEmail {l Wrote}:charlie: I am sorry, but I don't appreciate flaming. As I mentioned in one of my previous posts I was going to help this project out at a minimum of scripting & rendering, but was also debating on GPL'ing a Irrlicht based engine I developed for a failed game called SoulForge (that's that "naive assessment/90% done" thing you are referring too). But I really don't like you, so have a nice day.


Hmm

MyEmail {l Wrote}:Consider for a second if you where to import Irrlicht, create a sub-class of the BSP node-class to add any additional features your engine requires, and be 100% done with your dungeons rendering code in a week of work?

...by basing this off of Irrlicht literally 90% of your code would be done.


Naive. A weeks worth of work. Naive beyond despair. You'd have a project toilet itself on a personal whim. And you say I'm flaming.

If it's so damn easy, just a mere week's worth of work by your measure, then I challenge you to do it, a person who has not looked at the codebase or even the requirements of OpenDungeons, I challenge you to do in a week what has taken these guys a few years. If you can port OpenDungeons in a week to Irrlicht to the point it is playable and has done "literally 90%" of the code, I will post a formal retraction on FreeGamer, YouTube, and I'll kiss an object of your selection.

Like me or not, I don't care, but I don't like dangerous suggestions like yours. It's whimsical, based purely on your own pursuits, and is not a suggestion made with the health of the project in mind, merely your preferences. You are coming across as the worst kind of potential contributor; "I'll contribute but only if you do it my way." That kind of contributor usually does damage then leaves.

MyEmail {l Wrote}:Ok, well I was kinda implying I would help you guys out to get the basics going (rendering & scripting) but it seems your better off on your own. Best of luck with the project.


Am I wrong? Show me up, make me look foolish.
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2130
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: What about Irrlicht? (with feature suggestions)

Postby MyEmail » 08 Jul 2011, 18:04

charlie:
    You are making wild conjectures and pulling my words out of context. The "weeks worth of work" was in reference to your dungeon rendering code, which would take a full work- week of work to complete. Furthermore, in an entire game your "glue code", or the code that implements your game logic, might hit 20,000 lines of code in a large project. Irrlicht is composed of 272,424 lines of code--which means the measly 20,000 lines of glue-code would make up for approximately 6% of the entire game engine (hence the fact that importing a large codebase like Irrlicht takes care of "90%" of the work for you).

    When working on large-scale projects from scratch its an enormous amount of work--Compression (Huffman, range, rle, and lz coders), filesystem management (multi-platform file I/O, reading/writing to/from ZIP, PAK, TAR, etc, archives; temporary file management, etc), data loading/parsing (PNG, JPEG, TGA, MD3, MD5, MD2, OBJ, BSP, OCT, GLSL shaders, etc etc), math library (2/3/4D vectors, quaternions, matrices, 2/3D lines, 2/3D bounding boxes/spheres, SSE/MMX optimizations, etc), rendering platform (multi-pass scriptable node system, with support for GLSL shaders, ARB shaders, CG shaders, software shaders; depth, color, and cube-color framebuffers, etc etc etc).

    That's only touching extremely lightly on the vast amount of work that it requires to make a decent game-engine. As you can hopefully now see, by using Irrlicht (or for that matter, Ogre) you really do have 90% of the work done.

Now, to the competent developers:
    What is the goal for the rendering engine with regards to the dungeons/terrain? I assume you want a nice lighting system, with bump-mapping and unlimited lights, correct? What I would recommend is to setup a global light to be used for single-light bumpmapping (+ wang splatting), then use Bloom/HDR to implement the "unlimited lights" part (it ends up looking really nice). You could even throw in some SSAO and it would look really spiffy. More complicated systems could be implemented that take considerably more work than this (on the scale of months), but this is a quick'n'easy solution you can almost drop-into your code.

    So, what exactly are the goals for the dungeons rendering code?
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: What about Irrlicht? (with feature suggestions)

Postby MyEmail » 09 Jul 2011, 18:37

Here is some simple psuedo-code that with a Framebuffer and Shader class (I assume Ogre has something similar) and the appropriate GLSL shaders, will implement the above mentioned lighting system (+SSAO):

{l Code}: {l Select All Code}
// this would, of course, have to be addapted to Ogre's rendering system (hence it is psuedo-code).

class Framebuffer;  // some kind of wrapper to OpenGL's framebuffer extension
class Shader;  // some kind of wrapper to OpenGL's GLSL shader extension

Framebuffer * BloomFBO[2] = {NULL, NULL};
SceneDepthFBO * BloomFBO = NULL;
NormalFBO * BloomFBO = NULL;
Shader * bloomBlurShader;
Shader * combineBloomAndNormal_andAddSSAO;

// renders objects to the bloom buffer, things such as lights go here.
BloomFBO[0]->begin();
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   renderScene(renderFlag_bloom);
BloomFBO[1]->begin();


// renders the scene's depth
SceneDepthFBO->begin();
   glClear(GL_DEPTH_BUFFER_BIT);
   renderScene(renderFlag_depth);
SceneDepthFBO->end();

// renders the scene normally
NormalFBO->begin();
   renderScene(renderFlag_normal); // renders the normal scene
NormalFBO->end();

// renders the first bloom buffer to the second, apply a 2D-blur to it (makes lights glow around objects)
BloomFBO[1]->begin();
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   bloomBlurShader->enable(); // enable the bloom shader
   bloomBlurShader->uniformTexture("texture_0", 0); // binds "texture_0" in the shader to the first texture slot (aka: the bloom fbo)

   BloomFBO[0]->bind(0); // bind the first bloom FBO to the first texture slot
   
   drawQuadAcrossEntireScreen();
   
   BloomFBO[0]->unbind(0);
   
   bloomBlurShader->disable();
BloomFBO[1]->begin();

// BloomFBO[1] now contrains a light-overlay of the scene, which gets added to the NormalFBO.
// render everything to the screen, by combining the NormalFBO and BloomFBO[1], and adding SSAO from the SceneDepthFBO.
{
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   combineBloomAndNormal_andAddSSAO->enable();
   combineBloomAndNormal_andAddSSAO->uniformTexture("texture_0", 0); // bind the bloom FBO
   combineBloomAndNormal_andAddSSAO->uniformTexture("texture_1", 1); // bind normal FBO
   combineBloomAndNormal_andAddSSAO->uniformTexture("texture_2", 2); // bind the depth FBO

   BloomFBO[1]->bind(0); // bind the first bloom FBO to the first texture slot
   NormalFBO->bind(1); // bind the first bloom FBO to the first texture slot
   SceneDepthFBO->bind(2); // bind the first bloom FBO to the first texture slot
   
   drawQuadAcrossEntireScreen();
   
   BloomFBO[1]->unbind(0);
   NormalFBO->unbind(1);
   SceneDepthFBO->unbind(2);
   
   combineBloomAndNormal_andAddSSAO->disable();
}


The bloom could easily be adapted to the much-more-expensive light-scattering method (the light rays shinning through the mountain peaks in that video). The shader for this is slightly more complicated (and somewhat limited) in comparison to blooming, as it has to know the location of the light its scattering, and its definitely more of a performance hog (especially when you add multiple lights). Ideally you should have both bloom & scattering, and should use bloom for minor lights and scattering for major lights.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: What about Irrlicht? (with feature suggestions)

Postby svenskmand » 09 Jul 2011, 19:07

MyEmail {l Wrote}:What is the goal for the rendering engine with regards to the dungeons/terrain? I assume you want a nice lighting system, with bump-mapping and unlimited lights, correct? What I would recommend is to setup a global light to be used for single-light bumpmapping (+ wang splatting), then use Bloom/HDR to implement the "unlimited lights" part (it ends up looking really nice). You could even throw in some SSAO and it would look really spiffy. More complicated systems could be implemented that take considerably more work than this (on the scale of months), but this is a quick'n'easy solution you can almost drop-into your code.

So, what exactly are the goals for the dungeons rendering code?

Your assumption about our graphics goal sounds about right.
Jamendo.com - The best music store on the net, uses CC licenses.
User avatar
svenskmand
OD Moderator
 
Posts: 1850
Joined: 09 Dec 2009, 00:07
Location: Denmark

Re: What about Irrlicht? (with feature suggestions)

Postby MyEmail » 10 Jul 2011, 09:18

svenskmand {l Wrote}:Your assumption about our graphics goal sounds about right.


Thank you for your reply :). I will continue illustrating the lighting system, feel free to tell me your thoughts once you have read it (incompatibilities you foresee with your engine, if your confused, additional features, ideas, etc etc).

So, you could have four "priorities" or "types" of lights (1, 2, 4, 8). 1 refers to lights that are static and used to pre-calculate the lighting via lightmaps. 2 being lights used for real-time bumpmapping. 4 for bloom/hdr. 8 for scattering. Do note how I am referring to them via powers of two, so this can be implemented using bitflags (so a single light can have multiple priorities).

Here are the best combinations:
    1 & 4 would be a good combination. The pre-calculated lighting adds their effects to the terrain, while the bloom makes them seem real as they shine around objects (consider a static light that doesn't move, and whose intensity and color remains constant, but it looks more real because it shines around objects as if illuminating them).

    2 & 8 is also a good combination (consider a spotlight that moves back-and-forth, shining its rays around walls and casting a spotlight). Use it sparingly (on special lights) because its expensive (max of 4 lights per-camera view).

    4 works well by itself for large numbers of lights, especially when the lights must be dynamic (ex: headlights on a car, or a torch carried by a goblin).

If performance is an issue on some machines, add options to disable any and/or all of the lights by their priority. If a player disables scattering, you can still render 2 & 8 lights with just bumpmapping. If the player disables bloom, you can still render 1 & 4 lights with just pre-calculated lighting. Or visa-versa, etc.

Building on top of the previous pseudo-code, here is some more pseudo-code to render bump-mapped objects in a dynamically lit world with unlimited lights:
{l Code}: {l Select All Code}
class Light;  // wrapper to the OpenGL lighting system (use the Ogre equivalent).
class Shader; // wrapper to the OpenGL GLSL extension (use the Ogre equivalent).
class Objects;  // an object to be rendered (use the Ogre equivalent).

#define MAX_LIGHTS    8 // the maximum number of lights supported by the minimum target hardware

Shader * bumpMappingShaders[MAX_LIGHTS + 1]; // contains a GLSL shader for each lighting scenario (bumpMappingShaders[0] implements 0-light bumpmapping, bumpMappingShaders[1] implements 1-light bumpmapping, bumpMappingShaders[2] implements 2-light bumpmapping, etc). aka: its a performance hack.





enum lightFlags {
   lf_NONE       = 0x00000000, // this light does nothing
   lf_PRECALC       = 0x00000001, // this light is pre-calculated
   lf_BUMPMAPPING = 0x00000002, // this light uses real-time bumpmapping
   lf_BLOOM       = 0x00000004, // this light is rendered into the Bloom FBO.
   lf_SCATTER       = 0x00000008, // this light is rendered into the Scatter FBO.
   // additional types of lights go here
};

list<Light *> sceneLights; // contains all the lights in the scene
list<Objects *> sceneObjects; // contains all the objects in the scene

// loop through each object to render
foreach(sceneObjects, currentSceneObject) {
   Light * lights[MAX_LIGHTS]; // will contain the highest priority real-time lights affecting this object
   u32 index = 0;
   
   // loop through the lights and find the highest priority ones (please accelerate this using a octree!)
   foreach(sceneLights, currentSceneLight) {
      // if this light is affecting this object
      if(distance(currentSceneLight, currentSceneObject) <= currentSceneLight->radius) {
         // if an extra light slot is open
         if(index < MAX_LIGHTS) {
            lights[index++] = currentSceneLight;
         } else {
            // find the lowest priotity light currently affecting this object
            Light * lowestPriority = NULL;
            u32 clindex = 0;
            foreach(lights, currentLight) {
               if(lowestPriority) {
                  lowestPriority = currentLight;
                  clindex = currentLightIndex;
               } else {
                  // if the current light is lower priority
                  if((currentLight->intensity / distance(currentLight, currentSceneObject)) < (lowestPriority->intensity / distance(lowestPriority, currentSceneObject))) {
                     lowestPriority = currentLight;
                     clindex = currentLightIndex;
                  }
               }
            }
            
            // see if this light is higher priority than the lowest priority light currently affecting this object
            // if so, then replace the lower priority with the higher
            if((lowestPriority->intensity / distance(lowestPriority, currentSceneObject)) < (currentSceneLight->intensity / distance(currentSceneLight, currentSceneObject))) {
               lights[clindex] = currentSceneLight;
            }
         }
      }
   }
   
   // enable the appropriate shader (relative to how many lights is needed)
   Shader * cShader = bumpMappingShaders[index];
   
   cShader->enable();
   cShader->uniformTexture("texture_0", currentSceneObject->textureSlot0); // diffuse map
   cShader->uniformTexture("texture_1", currentSceneObject->textureSlot1); // normal map
   cShader->uniformTexture("texture_2", currentSceneObject->textureSlot2); // specular map
   cShader->uniformTexture("texture_3", currentSceneObject->textureSlot3); // ambient occlusion map
   
   // bind the textures
   currentSceneObject->textureSlot0->bind(0);
   currentSceneObject->textureSlot1->bind(1);
   currentSceneObject->textureSlot2->bind(2);
   currentSceneObject->textureSlot3->bind(3);
   
   // enable the lights
   // foreach(item, index, max)
   foreach(lights, clindex, index) {
      currentLight->enable(clindex);
   }
   
   // render the object (verts + tcoords + normals + tangents)
   currentSceneObject->render();
   
   foreach(lights, clindex, index) {
      currentLight->disable(clindex);
   }
   
   currentSceneObject->textureSlot3->unbind(3);
   currentSceneObject->textureSlot2->unbind(2);
   currentSceneObject->textureSlot1->unbind(1);
   currentSceneObject->textureSlot0->unbind(0);
   
   cShader->disable();
}



As you can see it is extremely simple, and you should be able to just plop it into Ogre's rendering system (+ the needed GLSL shaders). Took me about 30 minutes to write it, I would estimate an hour or two to implement the bumpmapping shaders (charlie: how am I doing on time so far? --said in a friendly, teasing manner :p ).




.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Re: What about Irrlicht? (with feature suggestions)

Postby oln » 10 Jul 2011, 10:59

Can the static part of the light model be used with dynamic terrain? Remember that the game is build around chopping down walls etc. , so the terrain is constantly changing. (Though i suppose it might be possible to implement some system that can alter the light map as things change.)

Concerning the implementation of a new lighting system. The rendering part of the engine was written by a developer who is currently not active, so neither of the ones that are active at the moment have really looked at how things like this would be implemented with Ogre. (So help there would be nice.) This is the main reason we haven't done much work on this part of the engine lately.
User avatar
oln
 
Posts: 1020
Joined: 26 Oct 2010, 22:16
Location: Norway

Re: What about Irrlicht? (with feature suggestions)

Postby Skorpio » 10 Jul 2011, 11:08

By the way has anyone heard of Andrew? I guess he's busy working on his PhD. Or has he lost the interest in OD?
User avatar
Skorpio
OD Moderator
 
Posts: 775
Joined: 05 Dec 2009, 18:28

Re: What about Irrlicht? (with feature suggestions)

Postby svenskmand » 10 Jul 2011, 12:19

He is working on a astronomical project for some professors, work related not studies as far as I understood. But he said he will be back at some point, maybe during the summer if I remember correct. But he will be back.
Jamendo.com - The best music store on the net, uses CC licenses.
User avatar
svenskmand
OD Moderator
 
Posts: 1850
Joined: 09 Dec 2009, 00:07
Location: Denmark

Re: What about Irrlicht? (with feature suggestions)

Postby MyEmail » 11 Jul 2011, 01:43

oln {l Wrote}:Can the static part of the light model be used with dynamic terrain? Remember that the game is build around chopping down walls etc. , so the terrain is constantly changing. (Though i suppose it might be possible to implement some system that can alter the light map as things change.)

Yup, there is a number of ways you can make this happen. The only concern is performance, but with proper measures it shouldn't be an issue. You would have to ensure:
    A) the lighting doesn't change too often (so it doesn't bog down the performance)
    B) If you use light-maps that they are low resolution (upon load time calculate a lightmap, if it takes longer than "X" acceptable milliseconds, then reduce the resolution, repeat. X would be calculated depending on the number of lights, the resolution of lightmaps, the number of lightmaps needed, and the speed of the CPU to ensure recalculating lightmaps doesn't cause lag)
    C) Use per-vertex lighting (much faster than lightmaps, but wouldn't have, for example, pre-calculated bumpmapping).

On top of that you can optimize things further by approximating the lighting, ie using lookup tables, etc.
MyEmail
 
Posts: 107
Joined: 06 Jul 2011, 08:58

Who is online

Users browsing this forum: No registered users and 1 guest