Irrlicht Engine

Well, if you really fear that your posting gets lost you should submit a bug ticket.

ent1ty wrote:I know, it's just.. They could at least drop by and say something like 'We know about it, we will fix it in the future.'.

Yeah sorry, I already know about it. But it will be a few more weeks until I'll find time again for Irrlicht coding, until then all I can do is put stuff on my todo (and there is a lot on it already...).

Feature request: Very simple to implement(i think)

I have a feature request.

in the class "array".

this will be the best (and fastest method) to erase a contiguos
piece of the array when the start or the end is included in the area to be deleted.
or maybe instead of using "option" we can use two new methods

array::eraseToEnd(u32 index);
array::eraseToStart(u32 index);


ok it is not a general case but maybe some one might be interested in that. just looking at the second branch of the conditional "option" you see that it is very fast.
If I find the way to improve that function also with ("option"== true) it will be included in the engine?

A little feature requests:
1. bool CSceneManager::unRegisterNodeForRendering(ISceneNode* node);
2. bool CSceneManager::isOk( ISceneNode* node); // for check alive scenenode in root
3. bool removeHighLevelShaderMaterial( s32 custom_mat_id );
best regards,

@wing64: Don't ISceneNode::setVisible, isVisible() do what you need in 1. and 2.?

wing64 wrote:A little feature requests:
1. bool CSceneManager::unRegisterNodeForRendering(ISceneNode* node);
2. bool CSceneManager::isOk( ISceneNode* node); // for check alive scenenode in root
3. bool removeHighLevelShaderMaterial( s32 custom_mat_id );
best regards,

1. Can be done with setVisible(false);
2. Can be done with if (Node->getParent()) EDIT: ok only works always when the parent is the root...hmm ok other idea. Node->setID(35453); if (Root->getSceneNodeByID(35353) == Node) and then set the ID back to what it was before
3. ok thats not possible

When will 1.8 be released? It has been quite some time, since the last release. I realize everyone has their own things going on, but its been a long time since the update, and Irrlicht generally updates itself rather fast. Well not updates itself, but a new release is usually seen realativley quickly.

@CuteAlien & @Sudi:
Thanks for respond my request and i understand you reply but setVisible(false) will effect in smgr in next time of main loop circle. If user is removed node after registered then smgr never know this node will lost or alive because engine not check node state when render function call.

@Sudi:
Why not possible ? i saw function for remove all material in null driver ( near remove all hardware buffer).

wing64 wrote:@CuteAlien & @Sudi:
Thanks for respond my request and i understand you reply but setVisible(false) will effect in smgr in next time of main loop circle. If user is removed node after registered then smgr never know this node will lost or alive because engine not check node state when render function call.

Sorry, I don't understand what you mean with "If user is removed node after registered". Visibility is a flag - so once set it stays. If you want to change that flag only at certain occasions you can do so. Not sure what you need - but maybe another thing is useful for you to know - you can grab() scenenodes yourself and keep them in some custom structure even if they are not part of the scenegraph. Then they are not rendered, but also not deleted and you can add them back to the scenegraph at some other time.

I've been wondering also something about the bone animated meshes that i think it could improve the performance. I don't know how much though, but i think it could be useful. Besides it is an improvement that can be passed to any kind of skin methods (hardware based or not) because it works on the basic mesh.

The rough idea is to split a skinned mesh into polygons of 2 types: Flexibles and Rigids.

Flexible polygons are polygons whose vertices are bound to more than one bone, and the Rigid polygons are those whose vertices are all tied to the same bone.

The point would be to render the rigid polygons from static meshbuffers, perhaps one per bone, because they need no deformation at all, only the matrix transformations, that can be passed directly to the hardware, and that the flexible polygons are the only ones calculated in the skin process. They can be calculated as usual.

More or less that's the idea. Would it be feasible? maybe too complex?

Sometimes its necessary to rotate scene node about custom point (which is not belongs to scene node' mesh, its temporary (just like in Blender when you can rotate object about current cursor position)).

So i would like to propose to extend ISceneNode with next methods: Pivot value should be store within scene node and by default it should be equals to local scene node center -- <0,0,0>; and setPivotRotation() should just do additional rotation just like setRotation() do now, but when Pivot changes to something other than <0,0,0>, it also changes final object position and rotation because of its meaning.

The image of setPivot() and setPivotRotation() in action:


Also same extending for scalling would be great:

But you can do that easily with matrix.

stefbuet wrote:But you can do that easily with matrix.

Code: Select all

core::matrix4 m;
m.setRotationCenter(myCenter);
m.setRotationDegrees(myRotation);
core::matrix4 from;
from->setRotationAngle(node->getRotation());
from->setTranslation(node->getPosition());
core::matrix4 newM=m*from;
node->setPosition(from->getTranslation());
node->setRotation(from->getRotation());

yes yes.
Also irr::scene has only helping classes, and indeed all which is really necessary is irr::video functionality. I know that.

I know that somehow with matrices its possible to do all those complex rotations, but Irrlicht suppose to be simplest graphic engine i believe. My math is very bad when it comes to matrices and vectors.

P.S.: Thank you any way for the code, i will try it.

btw greenya
did you think about using an emptyscenenode as pivot? that would do what ya want.

Sudi wrote:btw greenya
did you think about using an emptyscenenode as pivot? that would do what ya want.

thanks, good idea!