Ogre Procedural [v0.2 officially out]

[Mikachu]

@Falarys : it might be the triangulator that gets stuck on something... it sometimes lacks robustness.
You can create a debug mesh directly from your multishape to visualize it, does it look ok?
If so, could you provide me sample data to reproduce the issue?

@Transporter : using CMake to run external programs is relatively straightforward, I've done it in luatests project to automatically generate SWIG bindings, and also in docs project to call doxygen and asciidoc.

[Transporter]

Code: Select all

How to build the docs
---------------------

1. Install doxygen, graphviz, python, xlstproc and add their bin directory to the system PATH
2. Install asciidoc and set ASCIIDOC_DIR in CMake
3. Build the illustrations project to create illustrations images, which will be used in the manual and doxygen docs
4. Build the doc target to create the doxygen api docs
5. Build the manual target to create the manual

Is it really necessary to build the documentation in such a complicated way? Why do you don't use doxygen for the manual and the API docs? You can create documentations without source code, too. Why not integrating the manual in the API docs (like AbiWord or Expresso but with more pages)? Why do you use asciidoc instead of LaTeX? CMake supports "LaTeX projects".

[Mikachu]

Is it really necessary to build the documentation in such a complicated way? Why do you don't use doxygen for the manual and the API docs? You can create documentations without source code, too. Why not integrating the manual in the API docs (like AbiWord or Expresso but with more pages)? Why do you use asciidoc instead of LaTeX? CMake supports "LaTeX projects".

Actually, I prefer generating docs from asciidoc because as a text input, it's better integrated into versioning system (it diffs better than markup languages), and it's also easily human readable.
I would not exactly call LaTeX something easy to install and use... it's better suited for big writing projects, and seems a bit overkill for my purpose (and not to mention the 750 MB distro to download).

Now, about simplifying the process of building docs :

• I can maybe ease the 1. and 2. steps by providing a zip archive with every doc dependency inside.
• I could also merge 3,4 and 5 into a single step, but I would rather not to, since the illustrations is a bit long to create svg files.
• And, as I said earlier, I can nightly build the manual and the API doc, and put them both online and as a downloadable archive.

I'll try doing all these before weekend, IMHO it should already simplify things out for 99% users.

[Transporter]

• I can maybe ease the 1. and 2. steps by providing a zip archive with every doc dependency inside.
• I could also merge 3,4 and 5 into a single step, but I would rather not to, since the illustrations is a bit long to create svg files.

I already deleted that svg output code again, because I can't use SVGs for texturing doc. I also improved the building of api & manual by setting illustrations as a dependency of manual & api. Including asciidoc python scipt would help a lot.

[Transporter]

It's patch time You like to have a couple of smaller patches, so I split my patch into many parts. You can find the whole patch at once in the next posting.

Patches - Part 1

• Changes int to unsigned int in all components for segment counter variables
• Remove compiler warnings for mixing signed and unsigned data types by explicit casts
• Improve tags for doxygen
• Add images from the manual to API doc
• Remove doxygen warnings for wrong parameter doc

• Moves rapidxml callings to an internal helper class which is not a part of the ogre procedural SDK
• Update SVG example

• Update CMake for Ogre 1.9.0
• Update TutorialFramework (see http://www.ogre3d.org/forums/viewtopic.php?f=4&t=72533) which is used by the examples

[Transporter]

Patches - Part 2

• Update doxygen template (html.cfg.in)
• Update CMake to locate python
• Set Illustrations as a dependency for doc- and manual-project
• Execute Illustrations before building doc & manual to create the images *

* Look at the texture patch to fix/update illustrations code!

• Add procedural texture creation to ogre-procedural
• Update Illustrations to create pictures and graphs for texture filters
• Update Illustrations by removing SVG exports which are not usable for colored pictures (only for sketches and drawing)
• Add texture example
• Add additional pages to doc for textures (manual.dox) overview and description

[Transporter]

Corrections of revisions 4eb8f0efaf43 and 3b6148dbd4ac
You forget to change CMakes of the the samples. It's not working if you only change the tutorial framework and don't link the overlay component. You only linked the Sample_Primitives project:

Code: Select all

if(${OGRE_VERSION} VERSION_GREATER "1.8.1")
	include_directories(${OGRE_Overlay_INCLUDE_DIR})
	target_link_libraries(Sample_Primitives ${OGRE_Overlay_LIBRARIES})
 endif()

But you linked it in the wrong file /samples/CMakeLists.txt instead of /samples/primitives/CMakeLists.txt. The other samples are missing.

[Mikachu]

@Transporter : oops, I see, I thought I was factorising code, but I overlooked the fact it was not the same code everywhere.. I'll fix that.

[Transporter]

I've compiled a small SDK for ogre procedural users who like to test my texturing extension:

• ogre-procedural-vc100-amd64.7z
• ogre-procedural-vc100-x86.7z

Everything is documented in API docs. I try to make it simple by adding pictured graphs to see how it works.

ogreprocedural-xxl2-r3b6148dbd4ac.zip

[noorus]

I tried to compile Ogre Procedural from fresh Hg-provided source against a fresh default branch source-compiled Ogre, and ran into some problems.

This I had to take out from the CMake, because it was trying to run but failing:

Code: Select all

if(${OGRE_VERSION} VERSION_GREATER "1.8.1")
	include_directories(${OGRE_Overlay_INCLUDE_DIR})
	target_link_libraries(Sample_Primitives ${OGRE_Overlay_LIBRARIES})
endif()

Then, when compiling the samples, I had to undefine OGRE_EXTERNAL_OVERLAY, because Ogre 2.1.0unstable apparently doesn't know what it is.
Yet I also had to change

Code: Select all

#ifdef OGRE_EXTERNAL_OVERLAY
	OgreBites::InputContext input;
	input.mAccelerometer = NULL;
	input.mKeyboard = mKeyboard;
	input.mMouse = mMouse;
	input.mMultiTouch = NULL;

	mTrayMgr = new OgreBites::SdkTrayManager("InterfaceName", mWindow, input, this);
#else
	mTrayMgr = new OgreBites::SdkTrayManager("InterfaceName", mWindow, mMouse, this);
#endif

to

Code: Select all

	OgreBites::InputContext input;
	input.mAccelerometer = NULL;
	input.mKeyboard = mKeyboard;
	input.mMouse = mMouse;
	input.mMultiTouch = NULL;
	mTrayMgr = new OgreBites::SdkTrayManager("InterfaceName", mWindow, input, this);

in BaseApplication.cpp.
After that, everything compiled and runs fine.

[Mikachu]

Then, when compiling the samples, I had to undefine OGRE_EXTERNAL_OVERLAY, because Ogre 2.1.0unstable apparently doesn't know what it is.

That's because the overlay component is new in Ogre 1.9, and it hasn't yet been merged into 2.0 and default branches.
If I were you I would use the 1.9 branch of Ogre, unless you absolutely need to test what will be in later revisions...

The active branches really are 1.8 (for maintenance) and 1.9 (for new features), above that is only for experimental stuff at the moment

[Transporter]

This I had to take out from the CMake, because it was trying to run but failing:

Code: Select all

if(${OGRE_VERSION} VERSION_GREATER "1.8.1")
	include_directories(${OGRE_Overlay_INCLUDE_DIR})
	target_link_libraries(Sample_Primitives ${OGRE_Overlay_LIBRARIES})
endif()

Hm, what's not working? What's CMakes message?

Then, when compiling the samples, I had to undefine OGRE_EXTERNAL_OVERLAY, because Ogre 2.1.0unstable apparently doesn't know what it is.

That's really strange, because it's defined in BaseApplication.h:

Code: Select all

#if OGRE_VERSION > ((1 << 16) | (8 << 8) | 1) 
#define OGRE_EXTERNAL_OVERLAY 
#endif

I can find the ogre overlay component only in 1.9.0 branch, that's the reason why it's working only above 1.8.1. If ogre overlay is already included in 1.8.1 you just have to change

Code: Select all

#if OGRE_VERSION > ((1 << 16) | (8 << 8) | 1)

to

Code: Select all

#if OGRE_VERSION > ((1 << 16) | (8 << 8) | 0)

and

Code: Select all

if(${OGRE_VERSION} VERSION_GREATER "1.8.1")

to

Code: Select all

if(${OGRE_VERSION} VERSION_GREATER "1.8.0")

[noorus]

Well, I switched to the 1.9 branch after you pointed it out, but OgreProcedural still had a problem
The samples weren't linking to OgreOverlay.lib, so I had to add that by hand to all the projects.

[Transporter]

Well, I switched to the 1.9 branch after you pointed it out, but OgreProcedural still had a problem
The samples weren't linking to OgreOverlay.lib, so I had to add that by hand to all the projects.

I know, Mikachu forget a part of my patch. But it is solved in revision 4fa159025d23 just update your OgreProcedural copy.

[dudeabot]

Hello, in the extrusion sample, how would I go to have a linear road (with sharp angles), o do not sue the splines? i could replace cubicspline with what? thanks

[Transporter]

Yes, you can! Feel free to create a path from any form you like.

[Mikachu]

i could replace cubicspline with what?

Replace it with Path, and directly add points to it, something like this:

Code: Select all

Path p;
p.addPoint(0,0,0).addPoint(0,0,10).addPoint(10,0,10);

Splines are just a convenient way to produce smooth paths, but it's not compulsory at all...

[Transporter]

It's patch time again

Patches are built on revision 7ff418dfad1e

Patches - Part 1

• Improvement for boost detection
• The current code

  Code: Select all

  if ((${OGRE_VERSION} VERSION_EQUALS "1.9.0") OR (${OGRE_VERSION} VERSION_GREATER "1.9.0"))

  in samples CMakes is not working! The documentation said it is VERSION_EQUAL without S

• Add primitive triangle shape
• Implement Issue 90 (Shape::mirror)
• Add primitive shapes to Illustrations to create images for the docs

[Transporter]

Patches - Part 2

• Hide rapidxml from users by exporting XML reading functions from ProceduralSVG to ProceduralSVGHelpers
• Fix spacing in SVG sample

svg.patch

• Doxygen template improvements (html.cfg.in)
• Add groups to documentation since my texture classes are mixed up with the geometry stuff (this makes it easier to read api doc)
• Add more images to classes (for example: primitive shapes)
• Fix missing namespace (Texture) in example codes
• Add overview with images and index to api doc (manual.dox)

--------------------------------------------------------------------------------------------------

ogreprocedural-xxl3.zip

[dreamig]

Hi,
i want to draw a cylinder, i made a some resarch and i found this
http://www.ogre3d.org/tikiwiki/tiki-ind ... ry+Library
and because i use visual c++ i downloaded "OgreProceduralSDK_vs10_v0.2"
to use it i just
past the "OgreProcedural_d.dll" in the "C:\OgreSDK\OgreSDK_vc10_v1-7-4\bin\debug"
past the .lib of the OgreProceduralSDK_vs10_v0.2 in the directorie "C:\OgreSDK\OgreSDK_vc10_v1-7-4\lib\debug"
past the header files in the "C:\OgreSDK\OgreSDK_vc10_v1-7-4\include\OGRE"

and i create scene i make like that

Code: Select all

  mSceneMgr->setAmbientLight(Ogre::ColourValue(0.5, 0.5, 0.5));

	Procedural::SphereGenerator().setRadius(5.f).setUTile(.5f).realizeMesh("mySphere");
mSceneMgr->createEntity("mySphere");

    // Create a light
    Ogre::Light* l = mSceneMgr->createLight("MainLight");
    l->setPosition(20,80,50);

i added of course "#include"Procedural.h""

i haven't errors but when i execut it doesen't work, it show me this message

errorrr.jpg

but if i delete this lines
Procedural::SphereGenerator().setRadius(5.f).setUTile(.5f).realizeMesh("mySphere");
mSceneMgr->createEntity("mySphere");
it work

[Mikachu]

@dreamig : that's because the binary SDK of OgreProcedural has been compiled against the 1.8 branch of Ogre (it's now the stable branch, you can use it safely )
The compiler/linker expects to run against the same version of Ogre it was used to compile OgreProcedural, and that's not the case.

So, you can either switch to Ogre 1.8, or compile OgreProcedural from source (not as complex as it may sound, step by step explanation is here : http://code.google.com/p/ogre-procedura ... HowtoBuild )

[DanielSefton]

Just passing by to ask about the possibility of adding better or more UV unwrapping options for models. For example, the texturing on the ends of a cylinder is horrible, on a sphere the textures condense at the poles, and on a rounded cube the textures are squashed on the edges. It would be great if there was at least a cube mapping option to evenly wrap textures around the entire model. It's actually a while since I first asked about this, I wonder if it's been thought about or brought up in this thread yet?

Thanks!

[Mikachu]

@DanielSefton :
I must admit it slipped down to low priority, but as it sounds easy to implement (compared to some other features), I may fix these soon.

the texturing on the ends of a cylinder is horrible

I'll change that one to a planar texture on top, just like the extruder.

on a sphere the textures condense at the poles

You can't mathematically map a plane texture to a sphere, but cube mapping would help, of course.

[DanielSefton]

@DanielSefton :
I must admit it slipped down to low priority, but as it sounds easy to implement (compared to some other features), I may fix these soon.

Yeah I think it's pretty essential, especially if you're trying to use it practically for game levels (in my case).

I'll change that one to a planar texture on top, just like the extruder.

To be honest the cylinder is the biggest problem for me, I use it a lot to create circular platforms. So if you could even just do that, that would be great.

You can't mathematically map a plane texture to a sphere, but cube mapping would help, of course.

I was thinking as well you could have an option for generating a "quadsphere", a spherized subdivided cube, the texturing around the sphere would be a lot more even that way.

[Mikachu]

I was thinking as well you could have an option for generating a "quadsphere", a spherized subdivided cube, the texturing around the sphere would be a lot more even that way.

I thought about it afterwards, that mapping a sphere with a cubic map is not just a problem of setting UVs, but also rearranging triangles where needed. (or else there would be some terrible artifacts around the seams, I faced this exact problem when implementing the IcoSphere)
So, maybe that a cube with consistent UV coords + spherify modifier would be the simplest solution.
You can 'star' issues 52, 130 and 131 in the issue tracker, if you want to be notified when I start working on these.