Page 9 of 11

Posted: Mon Feb 02, 2009 5:22 am
by dlangdev
Halifax wrote:Well no one is holding you back but yourself. If you feel you want that type of stuff, then merge the patch with your checkout.

Otherwise, no one is making you stay here.
You said it, bro, I moved on.

I'm here checking to see how things are going. I'll be back when I see things are moving again.

Bye for now.

Posted: Wed Feb 11, 2009 1:52 pm
by kaos
Virion wrote:i remember irrblend has its own binary irrmesh format, which is very fast. maybe can consider about that format?
This is very very important,(I think) + animation.

Now we depend of others formats.

Like ogre, blender to xml to bin.

why blender? it's free.

edit: And blender can to import many other formats.

Posted: Sun Feb 15, 2009 8:14 pm
by wITTus
Dynamic LOD for meshes please!! This is sooooo cool... 8)

Posted: Sun Feb 15, 2009 8:40 pm
by bitplane
wITTus wrote:Dynamic LOD for meshes please!! This is sooooo cool... 8)
I've looked at fast polygon reduction a couple of times, I've got a proof of concept here but I guess it's never going to become part of Irrlicht. The reason is that while the edge collapse method is reasonably efficient, it doesn't address the the problem of re-mapping the UVs, generating new textures and creating normal maps. It just isn't feasible to generate LOD levels at load time, it can't be done automatically because you need a human to tweak the settings to get decent results, and it requires a lot of processing and memory allocation.

We do hope to support rendering LOD levels eventually, but polygon reduction is a modelling tool problem and doesn't really have much to do with the rendering engine.

Posted: Sun Feb 15, 2009 9:24 pm
by Pyritie
bitplane wrote:
wITTus wrote:Dynamic LOD for meshes please!! This is sooooo cool... 8)
I've looked at fast polygon reduction a couple of times, I've got a proof of concept here but I guess it's never going to become part of Irrlicht. The reason is that while the edge collapse method is reasonably efficient, it doesn't address the the problem of re-mapping the UVs, generating new textures and creating normal maps. It just isn't feasible to generate LOD levels at load time, it can't be done automatically because you need a human to tweak the settings to get decent results, and it requires a lot of processing and memory allocation.

We do hope to support rendering LOD levels eventually, but polygon reduction is a modelling tool problem and doesn't really have much to do with the rendering engine.
jMonkeyEngine has a LOD thingy. You might want to take a look at that. :3

Posted: Sun Feb 15, 2009 11:33 pm
by Halifax
Doesn't the OGRE engine have real-time polygon reduction? I think I remember seeing a demo with the ogre head having its polygons reduced as you move further away and coming back in as you move closer.

I could be mistaken, but it may be worth a look to check how they did it.

Posted: Sun Feb 15, 2009 11:37 pm
by hybrid
This is usually done in discrete, pre-calculated steps. Which is also easily possible with Irrlicht.

Posted: Mon Feb 16, 2009 12:12 am
by bitplane
Like hybrid said, jmonkey and ogre just switch models depending on distance, as do most commercial engines like half-life 2.
afaik other engines like horde 3d and unreal 3 actually morph the vertex positions between the lod levels, but they're still pre-computed and are held in a special format that describes the morphing.

Posted: Mon Feb 16, 2009 1:03 am
by Halifax
Ah, okay. That makes more sense.

Posted: Mon Feb 16, 2009 5:02 pm
by wITTus
bitplane wrote:
wITTus wrote:Dynamic LOD for meshes please!! This is sooooo cool... 8)
[...] it doesn't address the the problem of re-mapping the UVs, generating new textures and creating normal maps.
Well, maybe you won't see the errors if you're far away enough. :)

Posted: Mon Feb 16, 2009 7:09 pm
by Strong99
if you're too far for errors maybe you can just use an ordinary cube or something ? 8)

QUAKE/SOURCE SDK tools to IRRlicht ideas to propose...

Posted: Fri Feb 20, 2009 2:48 am
by christianclavet
Perhaps, if somebody who know more about C++ could implement VMT/VTF support for textures/materials/Shaders.

Here is c++ library that could be working with IRRlicht, perhaps having a link code between the 2 libs so they can cooperate together. (like an IRRvtf thing :lol: )

http://www.wunderboy.org/sourceapps.php#vtf_shell
This library should permit the loading and writing of VTF files. This is the format used by Valve for the Source Engine SDK and is supporting a lot of features needed for games and high speed graphical applications.

We could also use this tool to convert textures files to VTF:
http://nemesis.thewavelength.net/index.php?c=178

With this you could import other files and prepare the textures used by the meshes.

While I was on this guy site, I found out a tool to take VMF files (HAMMER editor files) and convert them to QUAKE .MAP format. It can also do the reverse. But with it, I think I will be able to use HAMMER to create maps for Quake, compile the map then and have a BSP to load back in IRRlicht!

Look for CRAFTY there: http://nemesis.thewavelength.net/index.php?p=45

I think with those tools, we could have a quick way to create maps for IRRlicht. (Using Hammer then convert it, so IRRlicht can load it back)

Could be great in the future if the BSP loader could be improved further to support loading of the SourceSDK .bsp

The BSP format could also be used if IRRlicht implement someday an PORTAL occlusion system. These BSP compiler have VIS optimizer that generate all the data needed so the PORTAL occluder will be able to optimize the map. The only other "need" would be to interpret the AREAPORTAL nodes from the BSP.

Still dreaming, I know. I don't have the skill to implementing this right now.

Posted: Fri Feb 20, 2009 12:44 pm
by zillion42
well to quote someone:

"half the stuff he talks goes way over my head, the other half goes way way over"

this is my mustard:
I'd be in favour of a binary mesh format aswell. One that handles it all, once and for all, 2TCoords, normals, tangents, weights and animation.
because
There can't be no development for a pipeline if there is no platform
and
If there is no pipeline for an artist there wont be no art.

'''pipeline, pipeline, pipeline''' and thanks to all the 'developers'
http://www.youtube.com/watch?v=8To-6VIJ ... re=related

Posted: Wed Feb 25, 2009 6:25 pm
by Steel Style
Was thinking about Lod and impostors and those others occlusion method, I remember that bitplane worked on the last one.

BITPLANE IMPOSTORS VIDEO

Any news ? Maybe we can create a sub project about render optimisation (including the light manager by roberbog) where everybody work will be looked to fit Irrlicht and maybe better performance rendering big environnements.

Posted: Thu Feb 26, 2009 8:24 am
by hybrid
The light manager is already in the core engine :P