Ogre Procedural [v0.2 officially out]

[Transporter]

I have an urgent problem with the lathe generator!
I like to create a 45° mesh of the following shape:

diagram.jpg

But I only get a filled block:

result.jpg

Code: Select all

	Procedural::Shape s = Procedural::Shape()
		.addPoint(0, 0)
		.addPoint(3, 0)
		.addPoint(3, 5)
		.addPoint(1, 5)
		.addPoint(1, 5+1)
		.addPoint(4, 5+1)
		.addPoint(4, -1)
		.addPoint(0, -1);
	Ogre::MeshPtr mp = Procedural::Lathe().setAngleEnd(Ogre::Degree(45)).setShapeToExtrude(&s).realizeMesh("special_part");
	Ogre::Entity* m_pMeshZylinder = sceneMgr->createEntity("special_part");

What's wrong with that code?

[Mikachu]

What's wrong with that code?

Could you specify the shape's outside to the left and set it as closed, then retry?

[Transporter]

What's wrong with that code?

Could you specify the shape's outside to the left and set it as closed, then retry?

Thank you! This solves my problem. Btw, I'll fix the SVG-rapidxml-stuff tomorrow.

[Mikachu]

Sorry I don't know how to do this on gcc. The following appears to compile and run OK but just doesn't look right.

Code: Select all

    template<class Ch> class xml_node;
    ....
   void parseChildNode(MultiShape& out, rapidxml::xml_node<char>* pChild);
   void parseRect(MultiShape& out, rapidxml::xml_node<char>* pRectNode);
   void parseCircle(MultiShape& out, rapidxml::xml_node<char>* pCircleNode);
  void parseEllipse(MultiShape& out, rapidxml::xml_node<char>* pEllipseNode);
  void parsePolygon(MultiShape& out, rapidxml::xml_node<char>* pPolygonNode);
	void parsePath(MultiShape& out, rapidxml::xml_node<char>* pPathNode);
    Ogre::Real getAttribReal(rapidxml::xml_node<char>* pNode, const Ogre::String &attrib, Ogre::Real defaultValue = 0.0f);
	Ogre::Vector2 getAttribTranslate(rapidxml::xml_node<char>* pNode);

What makes you say it doesn't look right? There's the same forward declaration in rapidxml.hpp...

The only difference with the MSVC version is that template default argument is not in the forward declaration, as gcc doesn't like it.

Anyway, I've commited this fix to the repository, at least it makes compilation working again with gcc

[Transporter]

• Improvements for doxygen template (html.cfg.in):
  • using version number defined in cmake
  • add example codes
  • combine manual with api documentation
  • support for graphviz/dot
• Update SVG example
• Change struct line to class line
• Improve boost detection
• Fix rapidxml-include
• Update SVG parser

ogre-procedural-new.patch

[dermont]

Sorry I don't know how to do this on gcc. The following appears to compile and run OK but just doesn't look right.

Code: Select all

    template<class Ch> class xml_node;
    ....
   void parseChildNode(MultiShape& out, rapidxml::xml_node<char>* pChild);
   void parseRect(MultiShape& out, rapidxml::xml_node<char>* pRectNode);
   void parseCircle(MultiShape& out, rapidxml::xml_node<char>* pCircleNode);
  void parseEllipse(MultiShape& out, rapidxml::xml_node<char>* pEllipseNode);
  void parsePolygon(MultiShape& out, rapidxml::xml_node<char>* pPolygonNode);
	void parsePath(MultiShape& out, rapidxml::xml_node<char>* pPathNode);
    Ogre::Real getAttribReal(rapidxml::xml_node<char>* pNode, const Ogre::String &attrib, Ogre::Real defaultValue = 0.0f);
	Ogre::Vector2 getAttribTranslate(rapidxml::xml_node<char>* pNode);

What makes you say it doesn't look right? There's the same forward declaration in rapidxml.hpp...

lol I didn't even notice that.

Anyway there is still the "strnicmp" issue here (see original patch for the define to strncasecmp) in the latest default branch.

Code: Select all

/home/dermont/Development/OGRE/ogre-addons/procedural-default3/library/src/ProceduralSVG.cpp: In member function ‘Ogre::Vector2 Procedural::SvgLoader::getAttribTranslate(rapidxml::xml_node<char>*)’:
/home/dermont/Development/OGRE/ogre-addons/procedural-default3/library/src/ProceduralSVG.cpp:228:36: error: ‘strnicmp’ was not declared in this scope
/home/dermont/Development/OGRE/ogre-addons/procedural-default3/library/src/ProceduralSVG.cpp:231:78: error: ‘strnicmp’ was not declared in this scope
/home/dermont/Development/OGRE/ogre-addons/procedural-default3/library/src/ProceduralSVG.cpp:240:60: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
make[2]: *** [library/CMakeFiles/OgreProcedural.dir/src/ProceduralSVG.cpp.o] Error 1
make[2]: Leaving directory `/home/dermont/Development/OGRE/ogre-addons/procedural-default3'
make[1]: *** [library/CMakeFiles/OgreProcedural.dir/all] Error 2
make[1]: Leaving directory `/home/dermont/Development/OGRE/ogre-addons/procedural-default3'
make: *** [all] Error 2

[Transporter]

Anyway there is still the "strnicmp" issue here (see original patch for the define to strncasecmp) in the latest default branch.

I've included your patch in my one to fix the rapidxml issue by reorganizing the SVG classes.

• Update SVG example
• Improve boost detection
• Fix rapidxml-include
• Update SVG parser
• Add dermonts patch
• Add a polygon generator to create 2D meshs

Edit: New patch below

[Hanmac]

hay i want to ask if i could use some parts of "Ogre Procedural" inside my rubybinding?

i may not want to use your code directly only as inspiration because i may need more submeshs like

should be 16 submeshes, one per each section

[Mikachu]

Hi,
Ogre Procedural is licensed under MIT license (same license as Ogre), so yes, you can modify the source, take parts of it, even without republishing your changes
The only requirement is that if you redistribute your work, you include Ogre Procedural's license text in it (it may be in a simple license.txt).

[Hanmac]

hm because i dont use the code directly , and rewite it for my purpose (submeshes and make the code more ruby like)
so what is the best way
"the Procedural Mesh creating functions are inspired by 'OgreProcedural' (link) with is licensed under `MIT license' (see mit_license.txt)"

currently i dont thought about the licence from my project ... i thought about LGPL or MIT

[Mikachu]

so what is the best way
"the Procedural Mesh creating functions are inspired by 'OgreProcedural' (link) with is licensed under `MIT license' (see mit_license.txt)"

Yes, that seems right

But if it's just inspiration, you don't even need to bother...

[Falarys]

Hi,

just got started with Ogre and Procedural and tinkering around a litte bit.
Specifically I got a closed path (e.g. a rectangle) and I need to make a solid mesh out of it (in this example it would appear as a box). I thought Procedural might be the right way to go for this problem.
But all I really am accomplishing is a "box" with not bottom and top, so just the frame, which is kind of logical, because I probably only extrude a rectangle path. I cannot find a way to extrude the path like a plane, if you know what I mean. (actually not a plane, because it should be possible to have an arbitraty 2D shape).

Code: Select all

// Create the path for extrusion (height of the box)
Procedural::Path pathTest = Procedural::Path().addPoint(0, 0, 0).addPoint(0, 0, 10).close();

// Create the path for shape (shape of the box)
Procedural::Shape shapeTest = Procedural::Shape().addPoint(0, 0).addPoint(100, 0).addPoint(100, 100).addPoint(0, 100).close();

// Extrude and create mesh
Procedural::Extruder().setExtrusionPath(&pathTest).setShapeToExtrude(&shapeTest).realizeMesh("extrudedMesh");

Any help is much appreciated!
Thanks!

screenshot.jpg

[Mikachu]

In order to get the caps at both ends of the extruded shape, you need to have the 'capped' mode of the extruder on.
It is on by default, but it is automatically disabled when the extrusion path is closed, since it would have no meaning in that case. So, don't call close() on path and it should work.

[Falarys]

Thank your for the fast reply! Just removed the close() from the path and it works perfectly now!
When I think about it, it did not make sense to close the path
Thank you so much!

[Mikachu]

Btw, I implemented an other feature: I have a lua script support for ogre procedual. I can create new primitives by a script without recompiling my ogre program.

I didn't consider this at first, but I'm a bit curious what was your approach on the binding? (Luabind/tolua++/swig or raw lua?)

I'm currently setting up a test bench using swig bindings on lua, because I'm starting to think my "tweak a value"/recompile/restart cycle is too slow, especially when I need to make extensive tests on new features...
If I succeed, I may write a little step-by-step tutorial about that, it may be helpful to some people (at least it would have been useful to me )

[Hanmac]

about my problems earlier:

currently Procedural create only one big submesh ...
when I have a torus, and i want to give each section an other material
or in a sphere an per-section checkered materials?
or i have a pillar made of a Box and a Cylinder, and i want them do have different materials

could that be possible someday with Procedural? (i need to build my own part of it, but it seems that i cant do it alone )

[Transporter]

Btw, I implemented an other feature: I have a lua script support for ogre procedual. I can create new primitives by a script without recompiling my ogre program.

I didn't consider this at first, but I'm a bit curious what was your approach on the binding? (Luabind/tolua++/swig or raw lua?)

I use luabind to create geometry by a lua script file instead of creating meshs with a 3D application.

I also have a new patch for ogreprocedural:

• Add support for ogre 1.9.0
  • Update FindOGRE.cmake
  • Update examples cmake files
  • Update BaseApplication.cpp
• Improvements for doxygen template (html.cfg.in):
  • Update doxygen template
  • Using version number defined in cmake
  • Add example codes
  • Combine manual with api documentation
  • Support for graphviz/dot
  • Add support for svg export to illustrations project
• Improve boost detection
• Fix rapidxml-include
• Update SVG parser and example
• Add dermonts patch
• Change number of segments type from int to unsigned int
• Fix number of warnings for doxygen (unsupported char, error in param doc)
• Extend LinePath
• Update bezier curves

ogreprocedural-xxl1.zip

[Mikachu]

I'm currently setting up a test bench using swig bindings on lua, because I'm starting to think my "tweak a value"/recompile/restart cycle is too slow, especially when I need to make extensive tests on new features...

I managed to get my bindings working with SWIG.
It's the LuaTests subproject, which is build by enabling the CMake flag OgreProcedural_BUILD_LUA_TESTS.
Once in the project, you can tweak luatests.lua (in the media folder), and press F5 to reload the script.
I hope it's going to help me improve my prototyping..

I wrote a bit more technical details here

[Mikachu]

@Hanmac: I'm not sure to understand your need... you want to be able to specify one different material per face?

or i have a pillar made of a Box and a Cylinder, and i want them do have different materials

In that case, it's already possible : BoxGenerator creates a mesh, CylinderGenerator another mesh, you can give them different materials if you want.

when I have a torus, and i want to give each section an other material
or in a sphere an per-section checkered materials?

This would mean a big number of submeshes... You're probably aware that this is very inefficient from a hardware perspective, since you're multiplying the number of batches (very bad impact on performance)

What I can provide is a split function for TriangleBuffer, based on vertex position or triangle index...
Would that answer your needs?

[Mikachu]

I also have a new patch for ogreprocedural

Thanks for your contribution

I'll have a look at it, but I already have a few remarks :
- Next time, could you break it down into several little patches? I think the Ogre guidelines to submitting patches are interesting in that respect. It makes changes easier to review/apply.
- A number of chunks rewrite the file entirely because of line endings (LF->CRLF). I'd like to keep all text files to LF line endings to prevent such diffing problems.

Don't bother to correct and resubmit, I'll handle that myself for this time, but it's just guidelines for next time

[Transporter]

Thanks for your contribution

I'll have a look at it, but I already have a few remarks :
- Next time, could you break it down into several little patches? I think the Ogre guidelines to submitting patches are interesting in that respect. It makes changes easier to review/apply.
- A number of chunks rewrite the file entirely because of line endings (LF->CRLF). I'd like to keep all text files to LF line endings to prevent such diffing problems.

Ok, I'm sorry for that. I'll make small patches for XXL part 2 I have to look out for a solution about the line endings, because CRLF is standard on Visual Studio.

My next contribution (part 2) will be a procedural material generator to create materials on the fly.

[Mikachu]

CRLF is standard on Visual Studio.

I'm using Visual Studio 2010, and it has no problem handling LF source files.

My next contribution (part 2) will be a procedural material generator to create materials on the fly.

Do you mean a texture generator? That would be great!
(Material/Shader generation is already handled by RTSS, I think.)

I've been looking forward to integrating fxgen, because it already has an editor, but I wonder if it's still actively maintained? Latest commit is > 1 year old...

[Transporter]

I've been looking forward to integrating fxgen, because it already has an editor, but I wonder if it's still actively maintained? Latest commit is > 1 year old...

I tried fxgen, it's not really working Btw, the editors name is ProTex. I'll make it similar to fxgen, maybe it's also possible to support the file format of protex.

Edit: Maybe it's possible to write an resource manager extension of protext files. I'll have a look at issue 90. This is an easy one.

[Falarys]

I'm still tinkering with Procedural and I think I somehow mixed up the normals of the mesh (at least, that is my guess).

Here's my creation of the mesh:

Code: Select all

Procedural::Path path = Procedural::Path().addPoint(0, 0, 0).addPoint(0, 10, 0);
Procedural::Shape shape = Procedural::Shape().addPoint(0, 0).addPoint(100, 0).addPoint(100, 100).addPoint(0, 100).addPoint(-50, 50).close();
Procedural::Extruder().setExtrusionPath(&path).setShapeToExtrude(&shape).realizeMesh(name);

When looking at the attached screenshot, you can see that the shading of top is alright.
But the extruded part seems to merge the normals of vertices at the same position so that edges disappear.
Any clues what I might do wrong?
Many thanks!

screenshot_2.jpg

[Hanmac]

@Hanmac: I'm not sure to understand your need... you want to be able to specify one different material per face?

or i have a pillar made of a Box and a Cylinder, and i want them do have different materials

In that case, it's already possible : BoxGenerator creates a mesh, CylinderGenerator another mesh, you can give them different materials if you want.

yeah but this would make two meshs, but i want one mesh with two submeshs

when I have a torus, and i want to give each section an other material
or in a sphere an per-section checkered materials?

This would mean a big number of submeshes... You're probably aware that this is very inefficient from a hardware perspective, since you're multiplying the number of batches (very bad impact on performance)

What I can provide is a split function for TriangleBuffer, based on vertex position or triangle index...
Would that answer your needs?

so maybe a Torus with with 16 sections, is turned into a mesh with 16 sub-meshs

or is there a better way to do that?

PS: i am okay to say that the spliting is only optional and not enabled by default