Irrlicht Engine

What would it take to make irrlicht pass the blend weights and blend indices to the shader? I think sio2 had a modified version that did so for his hardware skinning, but I don't know as he included the source code (and the site isn't working so I suppose that's a moot point).

This needs larger interface changes for sure. Since we need to get the values back for collision tests, it's not just one way. And there's also no way currently to handle existing user-priovided vertex shaders together with these hw animation stuff. We probably also need a major update of the VBO things first, in order to access those structures more easily and in a common way.

Well. I think the vertices need to be held inside Irrlicht as well as on the card. Then collision tests can be applied to the vertices in Irrlicht. The restrictions this would imply would need to be looked at, I guess, but in principle having the vertices in both places means that today's functionality could be generally retained, with new rules being applied in areas of overlap. Don't know how far this can go, though.

Just thinking out loud, if we had a low polygon model in Irrlicht and a high polygon model on the card, it should be possible to skin and shadow. Yes?

If a physics package were being used, this would normally require duplication of vertices. I wonder if there would be another way of linking the physics vertices with those on the card, some kind of alias.

hi

is there a official wishlist?

I wish more control over the window. (pos, size, style) like glut

Multithreading
CommandLineParser
Mathematical Parser

getting Date/Time on locale settings
getting Hardware Drive Informations (C:\,System,FIXED,size(); D:\,Data,REMOVEABLE, E:\,"",DVD-ROM) etc
getting CPU Caps (Cores, Threads, SSE)
getting RAM Caps (Speed)
getting SYS Caps (Temperature, Fans) // ok thats discussworthy but overheating is a problem
getting more Console Control on all Devices (Colors)

I wish more helpful functions for printing Irrlicht Enums / Types / Classes

like
E_DRIVER_TYPE_TO_STRING()
E_MATERIAL_TYPE_TO_STRING()
EKEY_CODE_TO_STRING()

complete new and advanced common dialogs (FileOpen/Save, ColorChoose, FontChoose, Print)

I wish more helpful member functions for core::string<T>.

like

void replace(const core::string<T>& findTok, const core::stringc<T>& replaceTok);
void insert(u32 pos, const core::string<T>& insertTok);
void insert(u32 pos, const core::string<T>& insertTok, u32 length);
void erase(u32 pos, u32 length);

or simple geometric shape classes, like:

core::shape2d<T>; // basic class (BoundingRect as common Prop)
core::dot2d<T>;
core::line2d<T>;
core::box2d<T>; // with four edge colors
core::circle2d<T>;
core::bezier2d<T>;
core::path2d<T>;
core::text2d<T>;
core::spiral2d<T>;

core::shape3d<T>; // basic class (BoundingBox as common Prop)
core::path3d<T>;
core::sphere3d<T>;
core::cylinder3d<T>;
core::cone3d<T>;
core::pyramid3d<T>;
core::icosaeder3d<T>
core::bezier3d<T>;
core::text3d<T>;
core::helix3d<T>;
core::frustum3d<T>;

that can be drawn with driver->drawShape2D && driver->drawShape3D

driver->prepare2dview
driver->prepare3dview
driver->drawImage (no texture, a image)
driver->drawTeapot
driver->loadImage
driver->loadTexture
driver->saveImage
driver->saveTexture
driver->deleteImage
driver->deleteTexture
driver->drawText(V_ALIGN::LEFT, H_ALIGN::middle)
driver->drawRoundRect
driver->drawStippledLine
driver->fillPattern

better organized filename manipulation functions for IFileSystem

getAbsolute
getBasename
getExtension
getPathname
getParentPath

copyFiles
moveFiles
deleteDir(with recursive subdir delete)
makeDir
moveDir
copyDir
setDir
getDir
existDir
existFile
findFile
findFiles
findDir
findDirs
encryptFile
encryptDir
decryptFile
decryptDir

core::table<T> // simple 2d container with variable row length
core::matrix<T> // with gaussian solver, QR, jordan
core::tree<T> // like the ISceneNode, but much simpler and more common usable, like xml / svg tree (no rounds, no loops, but any number of children)
core::hermite<T>
core::lanczos<T>

more advanced FONT class like OGLFT but for all drivers. ( TextureBased, ImageBased, PolygonBased, Transparent, Antialiased for TTF, OpenType Fonts)

for simple fps games

ICompassSceneNode
IMinimapSceneNode
IMap2DSceneNode (like Gothic with positions of Entities, Players)
IMap3DSceneNode (like Starlancer, positions of entities on downscaled worldmatrix, pretty nice math effects)
IBodyCollisionBoxesSceneNode
IDestroyableSceneNode CGlassWindowSceneNode, CDoorSceneNode, CStairsSceneNode, CTableSceneNode, CDecalSceneNode, CBuildingSceneNode, CFenceSceneNode, CRoadSceneNode, CWallSceneNode
IWaterSceneNode
ITreeSceneNode
ITreeLeaveSceneNode
ITreeTrunkSceneNode
ISkyDomeSceneNode
ISkySphereSceneNode
ICloudSceneNode
IWeaponSceneNode CDeagleWeaponSceneNode, CAK47WeaponSceneNode CMP5WeaponSceneNode, CP90WeaponSceneNode, CWeaponUpgradeSceneNode, etc
IPlayerSceneNode CEnemySceneNode, CNPCSceneNode, CAnimalSceneNode
IEntitySceneNode CCargoBoxSceneNode, CAidKitSceneNode, CArmorSceneNode CAmmoSceneNode
IGrassSceneNode
IVehicleSceneNode CBuggyVehicleSceneNode, CTankVehicleSceneNode, CCarSceneNode, CTruckSceneNode, CHelicopterSceneNode
IStaticObjectSceneNode
CPlanetSceneNode
CAsteroidSceneNode
CRockSceneNode
CMountainSceneNode

Mesh Tesselation (CPU && GPU)

A integrated collection of Shaders for common purposes (Fresnel Water, Bloom, HDR, Normalmapping, Reflections, Cartoon, BumpMapping, RayTrace, RayCasting, PhotonMapping )

Advanced Terrain with LOD, fractal geometry, detailmapping, tessellation, destroyable (changeable), with brushes (round, sharp) to change height and textureblending

Integrated Lightmapping System, that calcs shadowmaps on any geometry

Boolean Operations for Meshes

a simple Backdrop Class that is always rendered first with moveable Texture (i.e. marquee not just beginScene(backgroundColor))

a base class IImage that has much more capabilities (scale, rotate, subImage, blend, filter, etc)

--> and a derived hardware-accelerated (if possible) ITexture class.

a svg renderer/reader/writer.
a pdf renderer/reader/writer.
a dwg renderer/reader/writer.
a dxf renderer/reader/writer.

a HalfLife 2 / CounterStrikeSource Model and Map importer/exporter

a XPM_Reader/Writer

a better collection of Cameras

IGUIConsoleWindow // with parser
IGUIServerFindDialog
IGUIServerCreateDialog
IGUIListviewWithTableAndThumbnails
IGUIChatWindow
IGUIMeshViewerWindow
IGUIImageViewerWindow
IGUIWindow

and so on.

There's no official wishlist, but we read this thread (and most others).

To be more concrete about your wishlist:

Multithreading is discussed once in a while, just search the forum. It's not trivial but certainly we all would like to stream levels.

Parsers - so far I don't really see why those should be in the graphics engine, I think you better use own libs for that. Same for date/time.
Hardware info - IOSOperator offers some and nothing speaks against adding more over time.
enum to string functions - we use so far string-arrays, but haven't them yet for every enum (and they are somewhat dangerous when they ever get out of sync as happened in the past). But yes, if it's missing for enums I suppose it's a good idea to add them.

I think many tool functions for strings belong not in the string-class, but should instead work with algorithms acting on iterators. Which is why I'm pretty much against adding more functions into base-classes - as then it has to be coded over and over for every base-class (lists, arrays - they all could use the same). Getting closer to STL is the better way.

geometry... we have rect and line already. The only other I missed so far was bezier which I think I saw implemented somewhere in the engine hardcoded, but should belong in a base-class. Others - I'm not really sure how much need is there for those, did you ever really need them or just make up a list with shapes? path for example is not so trivial to make general, but is often very game-specific. 3d shapes can be done better with meshes - not sure what base-classes should really do there.

also other classes - we have matrix already - adding additional solvers would mean someone has to code them (and please with tests!). Never missed any of the others so far when coding with Irrlicht, did you?

More advanced Font-classes will come as soon as we have decided on a way for serializing more stuff (serialization is the more basic problem and needed in several more places right now).

Some of the nodes you are missing are maybe ok, but can also be easy found when looking around on the forum a little. So they usually land in irrExt (http://sourceforge.net/projects/irrext/).

I'm the wrong guy to talk about shaders and light algorithms, although I fear I'm getting slowly sucked into learning that stuff ^_^.

If you write more advanced terrain - sure - more advanced sounds fine (and also rather fun to write, I wish I had time for such things).

Shadowmap calculations are not done in realtime anyway - so maybe better to do them with tools.

Boolean operations on meshes... cool, who codes 'em?

Don't know what you mean with Backdrop class - if you want to put a texture behind everything then put it on a mesh which has a fixed distance to the camera around the far-plane.

More advanced possibilities with images are one of hte most-wished features and I hope we get to those some day.

supporting some special format - not sure if we ever declined that so far when someone delivered it (working, tested!). Although I suspect a pdf reader might be a little overkill for a 3d engine which still struggles with the gui system :-)

In general I'm fine with adding new code - but *only* when it works and is well tested. I'm getting increasingly annoyed with code in the engine which isn't - as debugging code written by others is a very slow and frustrating process. I have spend now several weeks doing nothing but debugging through the editbox and still haven't managed to fix everything and it's getting harder and harder for me to find motivation to continue there with every new bug I find. Not to mention completely f*cked up dialogs like colorselect which simply does not work at all (and treeview ain't that much better - I'm still not sure if I even should start debugging that, as it might be faster writing it from scratch than trying to understand and fix it in the state it is right now). I think bad code is worse than no code at all (other people are free to think different about that). And unfortunately there are never many people offering working and tested code. So write code. Write tests. Test it well. Show it works. Make sure it fits into the engine and is future-safe as much as possible. Make sure the patches are always only doing a single thing. Then it has a high chance of getting added to Irrlicht. And if someone shows he can code that way then it's also possible to get into the team. We don't miss feature-wishes - we miss more good feature implementations.

Shadw map is not lightmap, and they are done in realtime. Also I fixed the color selection dialog (at least I think so...).
But to sum up this huge and unordered list from gerdb: Some things simply don't belong into a render engine, some things do already exist. Others were already discussed. For the rest I'd suggest to put up some code into the CodeSnippets forum or the patch tracker, and we will check if it can be added. If you don't have a working version yet, you should probably clean up the concepts, split them up into different threads, and let them be discussed in a larger round. This would at least raise their chances.

I don't think ColorSelectDialog got fixed by anyone - the interface is simply empty except for the constructor. It sends file-events(!) without any data. Maybe I'm missing how that dialog is supposed to be used.

Well, the code should be ok, just looks like the getColor methods are missing in the interface. The event is not set so far, as I'm not sure which way it should be used. Should it send events on each color choice, or just after the dialog was closed? And which color value should be sent? Also don't know if the event should be renamed (dialog_selected maybe?) or create a new event for the color dialog. But rendering and color conversion works for sure

*sigh* this is probably the wrongest possible place to start a discussion about colorselect. I was somewhat frustrated last night after debugging/fixing some editbox functionality 2 full days in a row (this time - more days last weeks) which never worked correct and was nevertheless checked-in and I'm still not finished with it (and don't want to take more free days for that right now). Especially frustrating when you spend most of your time because you miss a part of the way it was originally coded as simply happens if you have to dig through code you didn't write.

But back to colorselection - I somehow I doubt the other functionality is really tested if the class hasn't even yet the interface for it. I know it displays a pretty color circle, but if that was the hard work and the rest is trivial - why then did whoever the coder was not finish it? In my experience the usual reason is that some hard task is hidden in what looks trivial now and just adding an interface without knowing about it probably leads to something messed up. Which means the only real way to finish this is is first understanding the current code and then writing tests for it and for example comparing the results of the color-picking with screenshots and a color-picker in a tool like gimp. Don't worry, it's on my todo - around position 50 right now, but as new problems show currently up faster than I can fix them I'm not sure yet when to get to it.

Also another note about that long list of features. The stuff I code usually has one of the following priorities: a) It's broken and needs to be fixed, b) it's something someone needs right now (sometimes myself), c) it's something that will improve the basic architecture. That takes up my time already, so adding features just for the sake of features isn't something I'll be coding and I don't think it would be a good idea anyway.

hi, thx for the replies, i will add many threads to the codesnippet section, promised

the reason i like CommandlineParser, Date/Time, CPU Caps to be in the Engine, is that they would be plattform independant and working

A Backdrop class is simple and make nice results, and therefore should be in Engine

For me Shadowmaps or Lightmaps are Textures blended on Diffusetex and generated before (static) playing the game, but it should be generated/loadable/saveable by Engine.

I dont know how to use SVN or GIT at all, would be nice if someone explains it to me in this Forum, and how people contribute that way.

at FORUM ADMIN:

- Please seperate all main threads into categories from the irrlicht namespaces irr, core, io, video, gui, scene and sort all post in these categories,
for me it is really hard to find anything here, this thread too.

- Reduce restrictions to contributing Code, there must be space for me!

- Please let the server run link checks and notify Members if links are broken/dead, there are so many of them.

PS
we have to grow up the forum,
the german counterpart seems to be fullspammed by russians.

I want to congratulate you guys, you are making an excellent work! I just prefer to have a SDK that is stable than a SDK that is full of new features and bugs (New features rarely comes without any bugs). As for my wish list:

// Scene
- Scene loaders that we can iterate manually as: "load mesh, refresh scene, iterate" (I think you already done this, but I've not found relevant info how to use it yet). So it would be really on the way to have scene streaming loading capability.
- An improved flexible vertex system, so we could implement hardware skinning, with shaders, VBO's and dynamic lighting
- Deferred rendering (can I dream? )
- "Blob" projected shadows (As I've seen them used in Unity 3D)
- IRRlicht native animated mesh format, so we could work on meshes, change their attributes (textures, materials). I'm really happy that we have savers, but it would really be cool to have an animated mesh saver also. By the way is there a way to "edit" animation data?
- An easy way to use animation data on a specific node mesh of the scene. (So we could have a lots of instance of a mesh, but we could define a specific animation data for only one of the instance. We already have a feature to replace the animation data with another mesh, but it change all of the instances, so it limit the usefulness a lot.)
- Axis oriented billboards (fake trees, decors and perhaps imposters)
- An easy way to use decals. I think it may be implemented with Q3Levels shaders, (Perhaps only having an example how to use with custom levels would suffice)
- Customisation of the controls for the camera animators (we could define the controls keys/mouse button for each specific currently supported actions), there is the functionnality on the FPS camera animator, but I don't see a way to change this for the "maya" camera.

// GUI
- An image could be not only scaled but tiled (would be really useful with GUI skinning)
- Optionnal support for truetype font rendering (I mean a IRRlicht compiler flag that enable the support, not an extension)
- IS there a UTF8 conversion available when loading XML strings? (UTF to widestring?)
- 2D Boxes with an option to have rounded corners (corner are rendered only if the a radius parameter is entered, default to 0, so we could have/create easily GUI's that have rounder corners.) Clipping (clip box) would have to use this also. (image in a rounded corner box, would need to be clipped accordingly to the shape). Having a second parameter, it could render the box as a circle using the first parameter for the radius. So we could have an "office" main menu style round button.

// Primitives
- A "capsule" primitive creation. Could be useful for physics and as a base shape for the CollisionResponseAnimator (Could be used as a collision shape for it and be used in a character controller system). I would also like to have a choice to setup the CollisionResponseAnimator with something else than the elipsoid.

// OS Specifics
- Would be able to call "native" dialogs, mostly the file selector dialog, directory selector (in fact, any dialog related to file handling)
- Would have OS infos about drives, LOCALE info(English, French, ...) and other systems peripherals

Some of this will need to be implemented directly (Flexible Vertex system), and some other would surely go in IRRext. Is there a place we could have a list and description of the current extensions IRRExt? Perhaps a sticky post with all this describing the extensions?

EDIT: I decided to put the information about the current extensions of the IRRext project on the wiki http://www.irrlicht3d.org/wiki/index.ph ... extProject or by the main wiki page on the "add-on section".

gerd> As for commandlineparsing/date/time, c++11 will implement that. If yo ucan't use it, boost does an excellent job too.

Irrlicht is first and foremost a graphical engine, that's why I think dev should prioritize that. Moreover it's more fun for them than GUI debugging. The current gui is already very useful in its current state whereas the graphic part lacks some important features.

I think that the video driver should have driver extension support. That way certain features specific to one driver could be implemented there. For example: DirectX11 has constant buffers, which don't fit into Irrlicht's system very well. The video driver could have a "GetDriverExtension()" function, and it would return it's implementation of the IDriverExtension class. Which would have header files available for each different driver. Also, it would be nice to write the driver creation so that you don't have to recompile to implement a custom driver. Kindof a "plug and play" driver system.

christianclavet wrote: // Scene
- Scene loaders that we can iterate manually as: "load mesh, refresh scene, iterate" (I think you already done this, but I've not found relevant info how to use it yet). So it would be really on the way to have scene streaming loading capability.

christianclavet,

irrlicht already has scene loaders which can be manually iterated and i even posted a very basic example of how to do this for you (http://irrlicht.sourceforge.net/forum/v ... =1&t=43648). i even told you to let me know if the example wasn't clear enough to explain the concept, in which case i would have posted further information. my offer still stands, if you need any more information on this please do let me know.

i'm not sure why the topic of multithreaded scene streaming keeps coming up when the irrlicht developers have provided us with an interface to achieve this.

well, since i'm posting in this thread i guess i should at least post a request or two for irrlicht

in irrlicht 2.0 i would love to see the following:

- irrlicht containers replaced by stl containers
- move certain things into the library from irrext (why is bitplanes CBatchingMesh not included in the core engine, I see many people needing this functionality and the "it doesn't belong in a rendering engine" argument doesn't apply :p)
- move certain things out of the library into irrext (or some other project) such as the irrlicht gui, for example (and the "it doesn't belong in a rendering engine" argument cleary DOES apply here, in my humble opinion... and dropping them from engine means core developers like cutealien don't need to bash their head for 2 days straight, leave it to irrext developers)

I would like an option to use point sprites as hw billboards. Only one vert, automatically user-facing.