Ogre Procedural [v0.2 officially out]

[def87]

Assaf Raman already created a libraryfor that.

Yet, I thought such a feature would be useful, so I've registered an issueto generate some kind of 3d text using freetype.

Thanks for pointing "PolygonFont" out to me. I've used FTGL in the past, but only for textured fonts.
If I reach this on my to do list before you implementing it in Ogre Procedural I will try to update Assafs project...

[Mikachu]

@Klaim: I prefer the first solution, looks much simpler, and if it fixes the issue you had, it's worth the "cost".

[Klaim]

@Klaim: I prefer the first solution, looks much simpler, and if it fixes the issue you had, it's worth the "cost".

I put the changes there for ease of future exchange: http://code.google.com/r/mjklaim-ogre-procedural/
(maybe I should have used bitbucket instead...)

As you can see in the logs:
- includes have been changed
- FindOgre and FindOIS have been updated.

It's based on your upgrade from tonight.

It works in my build (I copy paste the content of Ogre Procedural repository into my setup and everything compiles).
However I didn't try with the SDK and the samples, so you should check that first.

[Klaim]

By the way, PVS-Studio points me some easy-to-fix problems in Ogre Procedural code.
To sum-up:

- You have tons of loops using iterators 'it' by incrementing it this way: it++. It can cause performance problems (see http://forums.codeguru.com/showthread.p ... stead-of-i and most well known C++ books) and the fix is to do ++it instead.
- In ProceduralTriangulator.cpp , the "void Triangulator::addToTriangleBuffer(TriangleBuffer& buffer) const" function contain a big if. PVS points that both branches are equivalent code. My eye can't catch a difference either but maybe there is a subtility?
- In ProceduralMultiShape.cpp, line 122: beware of the commented code and the indentation!!! You should check that this part is correct and add {} to differenciate which line goes with which if or else!
- In ProceduralPathGenerators.cpp, line 188:

Code: Select all

 			z += fac * mPoints[i].y;

Shouldn't it be

Code: Select all

 			z += fac * mPoints[i].z;

? If yes, then I'm positively surprised that PVS Studio pointed this error.

The other PVS warnings are not important I think.

If you don't have much time to fix these, I can do most of these fixes tomorrow morning but I need your confirmation on the second and last point.

[Mikachu]

I put the changes there for ease of future exchange: http://code.google.com/r/mjklaim-ogre-procedural/
(maybe I should have used bitbucket instead...)

Ok, I'll pull your patches from that.

- You have tons of loops using iterators 'it' by incrementing it this way: it++. It can cause performance problems (see http://forums.codeguru.com/showthread.p ... stead-of-i and most well known C++ books) and the fix is to do ++it instead.

This article states that using ++iterator instead of iterator++ only has an impact on performances for debug mode, the compiler optimizes it in release mode.
So it doesn't hurt replacing those, but is not really important either.

- In ProceduralTriangulator.cpp , the "void Triangulator::addToTriangleBuffer(TriangleBuffer& buffer) const" function contain a big if. PVS points that both branches are equivalent code. My eye can't catch a difference either but maybe there is a subtility?

I'm currently working on a patch that impacts the triangulator.
I also had noticed that repetition (it's probably a legacy thing), so don't bother fixing that..

- In ProceduralMultiShape.cpp, line 122: beware of the commented code and the indentation!!! You should check that this part is correct and add {} to differenciate which line goes with which if or else!

Ok

- In ProceduralPathGenerators.cpp, line 188:

Oops! I think I missed that one...
I think this one was implement for SVG loader, and wasn't tested.

[Klaim]

- You have tons of loops using iterators 'it' by incrementing it this way: it++. It can cause performance problems (see http://forums.codeguru.com/showthread.p ... stead-of-i and most well known C++ books) and the fix is to do ++it instead.

This article states that using ++iterator instead of iterator++ only has an impact on performances for debug mode, the compiler optimizes it in release mode.
So it doesn't hurt replacing those, but is not really important either.

I am sure compilers tend to detect this kind of thing but it is not guaranteed and highly depends on compiler flags. Also fast debug mode might be vital for, for example, some video games. This article is good but should try to use different compilers and setups other than just Debug and Release from VS.

I'll make the change on my repo, it shouln't cost anything anyway. I'll fix the z problem too then.

So for the other changes I let you check them, right?

[Transporter]

In ProceduralPathGenerators.cpp, line 188:

Code: Select all

 			z += fac * mPoints[i].y;

Shouldn't it be

Code: Select all

 			z += fac * mPoints[i].z;

Correct! Typo of me.

Oops! I think I missed that one...
I think this one was implement for SVG loader, and wasn't tested.

I missed that one, too. BezierCurve2 is used to create bezier curved shapes from SVG. BezierCurve3 is a copy of BezierCurve2 with a third axis to create bezier curved paths in space, but it is not used yet.

[Klaim]

Fixes are in my repo.

[VJoe]

This is a wonderful library. Many thanks for it.

I have one question regarding rotation that need an expert help.

Is it possible to specify a local twist rotation along the extrude axis, at a certain point?
For example I have to make a helical shape but I want to twist at some points, so that the outer edge of the bend is higher than the inner edged.

Application example:
Consider a car track or a roller coaster. If I want to make a banking angle, then I might need a little twist on the control point.

Thanks for the help.
Regards

[Mikachu]

This is a wonderful library. Many thanks for it.

You're welcome

Is it possible to specify a local twist rotation along the extrude axis, at a certain point?

Yes, on the extruder, you can use setRotationTrack().
There's a sample screenshot here.

[Mikachu]

I hate to be annoying, but I just encountered another interesting behaviour of the normals I guess.
I changed my material shading mode to flat and as you can see in the screenshot the extruded object has a strange shading. In this scene I have a single directional light.
Do you know any way to come around this? Or might this be a lighting issue of the scene?

I'm not sure it's actually an issue, it's rather the way flat shading is working...
Do you have a specular component on your material?
That would be enough to explain the artifacts : the 2 triangle in a rectangular face both have the same normal, so with a directional light you'll have the same diffuse component.
However, specular calculation also involves the object/viewer position.
Since the 2 triangles don't have the same position, they have different lighting, and as there's no interpolation, a hard edge becomes visible...

[Klaim]

- You have tons of loops using iterators 'it' by incrementing it this way: it++. It can cause performance problems (see http://forums.codeguru.com/showthread.p ... stead-of-i and most well known C++ books) and the fix is to do ++it instead.

This article states that using ++iterator instead of iterator++ only has an impact on performances for debug mode, the compiler optimizes it in release mode.
So it doesn't hurt replacing those, but is not really important either.

I am sure compilers tend to detect this kind of thing but it is not guaranteed and highly depends on compiler flags. Also fast debug mode might be vital for, for example, some video games. This article is good but should try to use different compilers and setups other than just Debug and Release from VS.

About this, I just read this article that might be of great interest to anyone around, because it gets into practical depths of the problem: Is it reasonable to use the prefix increment operator ++it instead of postfix operator it++ for iterators?

[Mikachu]

@Klaim :
Oops, isn't that the same article that I linked above?
It was cross-posted on viva64 and codeproject...
But it's an interesting article, indeed.

[Mikachu]

Added a new small feature : show normals.
It could be useful for visual debugging..

showNormals.jpg

lua script for this sample:

Code: Select all

tests = Procedural.LuaTests_getInstance()
tb = Procedural.TriangleBuffer()
Procedural.BoxGenerator():setScale(2):addToTriangleBuffer(tb)
tb:transformToMesh("box")
Procedural.ShowNormalsGenerator():setTriangleBuffer(tb):setVisualStyle(Procedural.ShowNormalsGenerator_VS_ARROW):buildMesh("normals")
tests:addMesh("box")
tests:addMesh("normals", "BaseWhiteNoLighting")

[Klaim]

@Klaim :
Oops, isn't that the same article that I linked above?
It was cross-posted on viva64 and codeproject...
But it's an interesting article, indeed.

Right, sorry XD

[Falarys]

Thx for the normal visualization! Helps me a lot
I think i will try to detour and build my objects piece by piece, extruding every 2-point line, so I get non-averaged normals on the edges.

[duststorm]

Added a new small feature : show normals.

Great feature!

[Transporter]

Ogre Procedural Textures Preview
I'm nearly finished my procedural texture implementation. I like to show a small demonstration of it.

screenshot10102012_115235090.jpg

This is the code to create a smaller texture (4 x 32):

Code: Select all

	int brickLines = 4;
	int pxPerBrick = 32;

	Procedural::Texture::TextureBuffer bricks(brickLines * pxPerBrick);
	
	// Basic structure
	Procedural::Texture::Cell(&bricks).setRegularity(233).setDensity(brickLines).process();
	Procedural::Texture::Colours(&bricks).setBrithness(174).setContrast(198).process();
	Procedural::Texture::TextureBuffer distort(brickLines * pxPerBrick);
	Procedural::Texture::Solid(&distort).setColour((Ogre::uchar)125, (Ogre::uchar)133, (Ogre::uchar)0, (Ogre::uchar)255).process();
	Procedural::Texture::Rectangle rectDraw(&distort);
	for(size_t i = 1; i < brickLines; i++)
	{
		Ogre::ColourValue rc = Ogre::ColourValue((i % 2 == 0) ? Ogre::Math::RangeRandom(0.4f, 0.6f) : Ogre::Math::RangeRandom(0.0f, 0.2f), 0.52f, 1.0f);
		rc.a = 1.0f;
		rectDraw.setRectangle(0, i * pxPerBrick, brickLines * pxPerBrick, i * pxPerBrick + pxPerBrick).setColour(rc).process();
	}
	Procedural::Texture::Distort(&bricks).setParameterImage(&distort).setPower(50).process();
	Procedural::Texture::Cloud(&distort).process();
	Procedural::Texture::Normals(&distort).process();
	Procedural::Texture::Distort(&bricks).setParameterImage(&distort).setPower(8).process();

	Procedural::Texture::TextureBuffer normal(&bricks);

	// Normal map & lightning
	Procedural::Texture::TextureBuffer light(&bricks);
	Procedural::Texture::Colours(&light).setColourBase(0.325f, 0.0f, 0.0f, 0.0f).setColourPercent(0.78f, 0.443f, 0.333f, 1.0f).process();
	Procedural::Texture::Normals(&normal).process();
	Procedural::Texture::Light(&light).setNormalMap(&normal).setColourAmbient(0.164f, 0.0f, 0.0f, 0.0f).setPosition(255.0f, 255.0f, 200.0f).setBumpPower(48).setSpecularPower(8).process();

	// Joint
	Procedural::Texture::TextureBuffer joint(&bricks);
	Procedural::Texture::Invert(&joint).process();
	Procedural::Texture::Threshold(&joint).setThreshold(200).setRatio(255).process();
	Procedural::Texture::Colours(&joint).setColourBase(0.215f, 0.207f, 0.137f, 0.0f).setColourPercent(0.294f, 0.266f, 0.345f, 1.0f).setBrithness(110).setContrast(153).process();

	// Additional structure
	Procedural::Texture::TextureBuffer colourcloud(&bricks);
	Procedural::Texture::Threshold(&colourcloud).process();
	Procedural::Texture::TextureBuffer cloud(&bricks);
	Procedural::Texture::Cloud(&cloud).process();
	Procedural::Texture::Combine(&colourcloud).addImage(&cloud, Procedural::Texture::Combine::METHOD_MULTIPLY).process();
	Procedural::Texture::Colours(&colourcloud).setColourBase(0.329f, 0.141f, 0.0f, 0.0f).setColourPercent(0.95f, 0.949f, 0.862f, 1.0f).setBrithness(30).process();

	// Finish texture
	Procedural::Texture::Combine(&light)
		.addImage(&joint, Procedural::Texture::Combine::METHOD_ADD_CLAMP)
		.addImage(&colourcloud, Procedural::Texture::Combine::METHOD_ADD_CLAMP)
		.process();

	Ogre::TexturePtr demoTexture = light.createTexture("proceduralTexture");
	//Ogre::TexturePtr demoTextureNormal = normal.createTexture("proceduralTextureNormal");

	Ogre::MaterialPtr demoMaterial = Ogre::MaterialManager::getSingletonPtr()->create("proceduralMaterial", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
	demoMaterial->getTechnique(0)->getPass(0)->createTextureUnitState("proceduralTexture");
	demoMaterial->getTechnique(0)->getPass(0)->setSceneBlending(Ogre::SceneBlendType::SBT_TRANSPARENT_ALPHA);

Ok, this code is not so beautiful to read, so here you can see the process structure on an image:

demo.jpg

There are a still a few bugs in this code, so it was not planed to rotate the image on the second distort filter.

[Mikachu]

Definitely looks like a very useful addition to OgreProcedural !

Thumbs up!

[Klaim]

Wow that looks excellent procedural tool

[Transporter]

Thank you!

I'll add a few more filters and create a patch for ogre procedural. But there is one remaining question. How to create the doc? It would be nice to have images of the effects in the manual and the api doc to demonstrate the function. For main ogre procedural classes I can include SVG images directly in doxygen code, but converting a coloured image to SVG would increase the size of the source files a few times. There are two possible ways to resolve this problem:

1. Distributing the images via source code control.
2. Force building & running illustrations before creating the doc.

What do you think? I prefere the first option, because it's much easier for other people to build ogre procedural from source.

[Mikachu]

There are two possible ways to resolve this problem:
Distributing the images via source code control.
Force building & running illustrations before creating the doc.

I prefer the second solution, because I really don't like putting generated stuff into source control.

It's more complex for other people to build the docs, but :
1. I can document the process step-by-step.
2. The manual and api docs can be nightly built and made available, either as an online website (as it is currently the case, on ogreprocedural.org) or as a zipped archive (for those who prefer and offline version, for whatever reason).

[Klaim]

Same here, if there is a way to avoid putting images and non-text stuffs in the repo, it's always better.

[Falarys]

Just exploring the boolean operations a bit and encountered some errors on my difference operations.
I have a big shape and do some difference operations on them (the holes).
Most of the time it looks good, but I also get some destruction of the shape as seen in the screenshot:
Is it possible that some "unlucky" vertex position destroys the triangulation a bit? Or am I doing something wrong when applying the boolean operation?
Any help is much appreciated!

screenshot.jpg

[Transporter]

... as a zipped archive (for those who prefer and offline version, for whatever reason).

I prefer offline versions of help docs, because of a slowly and volume limited internet connection at home (not here ). I'll have a look how to get CMake running illustration prog before generating the doc. And I'll extend illustration by texture generation code to generate images.