Ogre Procedural [v0.2 officially out]

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogre Procedural [v0.2 officially out]

Post by PhilipLB »

Maybe some triplanar texturing on a sphere wouldn't look too bad?
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

PhilipLB wrote:Maybe some triplanar texturing on a sphere wouldn't look too bad?
Probably, since the particularity of triplanar texturing is to look good everywhere, whatever the geometry :wink:, and since it's now integrated with RTSS, it would be easy to use..

But I would at least like to provide consistent UV sets for the cases where performances are a concern (AFAIK, triplanar texturing needs 3 times more texture lookups)
OgreProcedural - Procedural Geometry for Ogre3D
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: Ogre Procedural [v0.2 officially out]

Post by PhilipLB »

You could calculate the UVs just like in the triplanar texturing shader. Then, just a single texture would be used for them probably, but that doesn't matter I guess.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

PhilipLB wrote:You could calculate the UVs just like in the triplanar texturing shader. Then, just a single texture would be used for them probably, but that doesn't matter I guess.
Yes, it would be possible by generating 3 UV sets, it would even work with fixed function...
But it would just skip the runtime UV generation, not the triple texture lookup, even with a single texture.
OgreProcedural - Procedural Geometry for Ogre3D
dudeabot
Gnome
Posts: 334
Joined: Thu Jun 28, 2007 2:12 pm
Location: Brazil
x 5
Contact:

Re: Ogre Procedural [v0.2 officially out]

Post by dudeabot »

on the behalf of feature requests. maybe its a bit too specific but ill give a shot anyway:

one way to do road intersections (or other type of other intersections), something like: http://www.youtube.com/watch?v=uyCcBt0JLvY

thanks in advance
[]'s
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

@dudeabot : the intersection feature is something that I thought about as soon as I started working the extruder, since I wanted to be able to create intersecting roads (I even created an issue for that, here)

It would be rather easy to do it the way that is shown in the video, but I would like to get a little bit more generic, for example to have branches of a tree joining at the trunk with no hard edges, or crossroad with road+sidewalk...
Eventually, I've come up with the idea that to handle it in a generic manner, I need to get boolean operations working first.
There's already an implementation of these in the repository, but it's not stable enough at the moment.

So I'll get back to road/pipes/trees/anything intersections as soon as CSG is working.
OgreProcedural - Procedural Geometry for Ogre3D
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

Based on 1f55db062f2c:
  • Hide rapidxml from users by exporting XML reading functions from ProceduralSVG to ProceduralSVGHelpers
  • Fix spacing in SVG sample
  • Add cycloid modifier to texture processing (including Illustration integration and help update)
  • Bugfix for Illustration project to create correct graphviz diagrams on texture modifiers
  • Bugfix for sample projects to initialize OverlaySystem before creating the GUI
  • Update of the help docs (image titles, ref links to API, etc.)
ogre-procedural-1f55db062f2c.patch
Update
(95.94 KiB) Downloaded 109 times
@Mikachu
I'll take care of issue 128 next week.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

Solved issue 128 on rev 58d50844286b:
  • Remove assert calls (issue 128)
  • Move parameter checks to input functions, if possible
  • Throw exceptions on error (issue 128)
  • Fix more signed/unsigned warnings
  • Fix spacing of sub structs in ProceduralTriangulator.h
  • Add setSize functions to PlaneGenerator and RoundedBoxGenerator like on BoxGenerator
  • Add parameter function to TriangleShape to create an equilateral triangle
  • Update/Add help of TextureBuffer since functions are not protected anymore from the user
ogre-procedural-58d50844286b-issue_128.patch
Issue 128
(98.66 KiB) Downloaded 103 times
I have a few more points which might be interesting:
  1. Issue 22 can be combined with issue 36. Using the paging/instancing methods would be the most efficient way to draw multiple instances of an object.
  2. Maybe it's helpful to create a resource loader class to load CAD data files and build the objects by ogre procedural.
josemarin2
Gnoblar
Posts: 18
Joined: Tue Aug 09, 2011 3:20 pm

Re: Ogre Procedural [v0.2 officially out]

Post by josemarin2 »

Great library, congratulations!


I would to create a racing car track.

How to generate the track, and to define how inclinated some curves are?

The samples I saw were only to generate Extrusions with the normal pointing up, but for curves I would like that that portion of the track is inclinated.

Thanks!

Jose
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

@josemarin2 : thanks :)

You would use, for example, CatmullRomSpline3 to generate the path with smooth curves (see here)

For the inclination, you would use a Rotation Track (see the effect here)

Its key defines where to put the inclination (with an adressing of your choice), its value gives the inclination of the road in Radians.
OgreProcedural - Procedural Geometry for Ogre3D
User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
x 10
Contact:

Re: Ogre Procedural [v0.2 officially out]

Post by DanielSefton »

Thanks for those changes! Cylinder caps are much better now. Would you mind posting a snippet which shows how to use the spherify modifier?
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

Bug in revision fe44de8e2ff4:

Code: Select all

..\..\library\src\ProceduralMeshModifiers.cpp(40): error C2065: 'mCenter': nichtdeklarierter Bezeichner
..\..\library\src\ProceduralMeshModifiers.cpp(40): error C2228: Links von ".length" muss sich eine Klasse/Struktur/Union befinden.
..\..\library\src\ProceduralMeshModifiers.cpp(43): error C2065: 'mCenter': nichtdeklarierter Bezeichner
..\..\library\src\ProceduralMeshModifiers.cpp(44): error C2065: 'mCenter': nichtdeklarierter Bezeichner
..\..\library\src\ProceduralMeshModifiers.cpp(44): error C2065: 'mRadius': nichtdeklarierter Bezeichner
mCenter and mRadius are not defined in ProceduralMeshModifiers.h!
  • Restore ProceduralMeshModifiers.cpp
  • Fix help after renaming Rectangle to RectangleTexture
bugfix.patch
Bugfix
(1.14 KiB) Downloaded 106 times
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

Transporter wrote:mCenter and mRadius are not defined in ProceduralMeshModifiers.h!
Oops, there's something I forgot to commit.
It's fixed now.
DanielSefton wrote:Would you mind posting a snippet which shows how to use the spherify modifier?
Sure.

Code: Select all

TriangleBuffer tb = Procedural::BoxGenerator().setNumSegX(10).setNumSegY(10).setNumSegZ(10).buildTriangleBuffer();
Procedural::SpherifyModifier().setInputTriangleBuffer(tb).modify();
tb.transformToMesh("sphere");
So you get a sphere with vertices organised differently, with no UV singularity at the top and at the bottom :
Before, texture
Before, texture
sphere2.jpg (20.72 KiB) Viewed 3614 times
After, wireframe
After, wireframe
spherify1.jpg (35.65 KiB) Viewed 3614 times
After, texture
After, texture
spherify2.jpg (34.92 KiB) Viewed 3614 times
Note that it's not fully usable yet, since all the sides of the Box have the same part of the texture (a 0,0 to 1,1 UV rectangle).
The UV modifiers I'll implement will address this issue.
OgreProcedural - Procedural Geometry for Ogre3D
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

Mikachu wrote:Oops, there's something I forgot to commit.
It's fixed now.
You also forgot to update the help after renaming Rectangle to RectangleTexture.
User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
x 10
Contact:

Re: Ogre Procedural [v0.2 officially out]

Post by DanielSefton »

The spherify modifier works great, thanks!

Despite the fact that I can use the spherify modifier now, I was just wondering if you thought the way icospheres are textured is correct. I know there's likely to be a singularity, but should it really be warping this badly? The singularity should at least be even?
Attachments
icosphere.jpg
icosphere.jpg (122.04 KiB) Viewed 3489 times
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

DanielSefton wrote:I know there's likely to be a singularity, but should it really be warping this badly? The singularity should at least be even?
Do you mean that it should look like the singularity in normal sphere?
In icosphere, there's only 1 vertex at the top (instead of n vertices in normal sphere), so there's also only one UV couple.
Thus, amongst the triangles touching the top vertices, only those whose UVs are relatively close to the top vertices will have low distortion...

That was one of the possible ways of implementing it : the singularity doesn't look even, but there's no need to do vertex splitting.
Anyway, things will improve as the various UV modifiers get implemented, which could be quite soon.. :)
OgreProcedural - Procedural Geometry for Ogre3D
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

  • Bugfix: Wrong output buffer in illustrations for Lookup filter
  • Bugfix: Two more changes after renaming "Rectangle" to "RectangleTexture"
  • Bugfix: Remove header for Ogre::Rectanlge (see rev 891eed0eaaae)
  • Update: Format code with tabs instead of spaces
  • Update: Rewrite Blit with parameter check (see rev 86717a02dc16)
  • Add: CircleTexture to draw circles and EllipseTexture to draw ellipses on textures
  • Add: Add Blit, CircleTexture and EllipseTexture to illustrations, manual and api-doc
ogre-procedural-blit.patch
Bugfix + New texture modifers
(60.56 KiB) Downloaded 81 times
Falarys
Gnoblar
Posts: 8
Joined: Wed Sep 05, 2012 11:07 am

Re: Ogre Procedural [v0.2 officially out]

Post by Falarys »

@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?
Hi,

sorry for my long absence. Work did get me hard :(
Anyway I now use already triangualted planes for drawing, then finding edges of that plane and extruding them.
This way I circumvent the issue to use the triangualtor on difficult planes with holes in it (which I sadly have).
I can still create a debug mesh with screenshot if you want? Although I don't need the robustness myself anymore.
Thanks a lot! All great work on this library :)
meerdov
Gnoblar
Posts: 1
Joined: Sun Dec 09, 2012 4:47 pm

Re: Ogre Procedural [v0.2 officially out]

Post by meerdov »

Hi. I am using Ogre Procedural for creating 3D text. I have a closed CubicHermiteSpline2, from which I get Shape. When I extrude this shape throw simple LinePath, I get an infinite loop while triangulating caps, in Triangulator::_addConstraints, here

Code: Select all

while (segments.size()>0)
		{
		//find next point
		for (std::set<DelaunaySegment>::iterator it = segments.begin(); it!=segments.end();++it)
		{            
Utils::log("it->i1 " + StringConverter::toString(it->i1));
            Utils::log("it->i2 " + StringConverter::toString(it->i2));
            Utils::log("pt " + StringConverter::toString(pt));

			if (it->i1==pt || it->i2==pt)
			{
				Utils::log("next " + StringConverter::toString(pt));

				if (it->i1==pt)
					pt = it->i2;
				else
					pt = it->i1;
				segments.erase(it);
				if (pt==itSeg->i2)
					isAbove=false;
				else if (pt!=itSeg->i1)
				{
					if (isAbove)
						pointsAbove.push_back(pt);
					else
						pointsBelow.push_back(pt);
				}
				break;
			}
		}
		} 
The problem arise when the Shape is created with setNumSeg(7). If it is created with setNumSeg(5), everything works correctly. For different splines the number of segments that causes the infinite loop is vary, in some cases it is 2.

Log:

[PROCEDURAL] it->i1 31
[PROCEDURAL] it->i2 60
[PROCEDURAL] pt 28
[PROCEDURAL] it->i1 36
[PROCEDURAL] it->i2 59
[PROCEDURAL] pt 28
[PROCEDURAL] it->i1 59
[PROCEDURAL] it->i2 60
[PROCEDURAL] pt 28
[PROCEDURAL] it->i1 27
[PROCEDURAL] it->i2 31
[PROCEDURAL] pt 28
[PROCEDURAL] it->i1 27
[PROCEDURAL] it->i2 36
[PROCEDURAL] pt 28
...........

Am I doing something wrong or is it a bug? thanks.
hall
Halfling
Posts: 41
Joined: Sat Dec 01, 2012 12:47 am

Re: must manually fix mingw linking problems to boost

Post by hall »

----- I fixed this by turning on "advanced" options in the cmake gui -----
building under mingw. I was successful, however, for illustration, sample/primitives, sample/extrusion, I had to manually add "-lboost-system...." in each of the "link.txt" files. Is there anything I should add to CMake or CMakeLists.txt to make this work automatically all of the time?
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

@Falarys @meerdov :
I know triangulator has some stability issues, especially with difficult shapes, ie shapes containing aligned points, duplicate points...
Also, rounding errors is a bit tough to handle..
LinePath is the typical example of such a difficult case.
I know I have to address this issue, at least by providing a wrong output rather than infinite loop or crash... also, the triangulator is used in my CSG algorithm, which can provide it with degenerate cases, so it has to get more robust.

@hall :
When Ogre is built with boost (it's the case of the prebuilt Ogre SDK), projects depending of Ogre must also link boost, and AFAIK, FindOgre.cmake doesn't detect it.
So, you can tell CMake where Boost is located (set BOOST_ROOT as an environnement variable or as a CMake variable).
If boost is distributed with Ogre SDK, inside a "boost" subdirectory, then OgreProcedural auto-detects it...
OgreProcedural - Procedural Geometry for Ogre3D
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: must manually fix mingw linking problems to boost

Post by Transporter »

hall wrote:Is there anything I should add to CMake or CMakeLists.txt to make this work automatically all of the time?
There is a boost detection included in CMake script of Ogre-Procedural. You just have to set BOOST_ROOT:

Code: Select all

# Find Boost
# Prefer static linking in all cases
if (WIN32 OR APPLE)
	set(Boost_USE_STATIC_LIBS TRUE)
else ()
	# Statically linking boost to a dynamic Ogre build doesn't work on Linux 64bit
	set(Boost_USE_STATIC_LIBS ${OGRE_STATIC})
endif ()
if (APPLE AND OGRE_BUILD_PLATFORM_APPLE_IOS)
    set(Boost_USE_MULTITHREADED OFF)
endif()
set(Boost_ADDITIONAL_VERSIONS "1.53" "1.53.0" "1.52" "1.52.0" "1.51" "1.51.0" "1.50" "1.50.0" "1.49" "1.49.0" "1.48" "1.48.0" "1.47" "1.47.0" "1.46" "1.46.0" "1.45" "1.45.0" "1.44" "1.44.0" "1.42" "1.42.0" "1.41.0" "1.41" "1.40.0" "1.40")
# Components that need linking (NB does not include header-only components like bind)
set(OGRE_BOOST_COMPONENTS thread date_time)
find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
if (NOT Boost_FOUND)
	# Try again with the other type of libs
	if(Boost_USE_STATIC_LIBS)
		set(Boost_USE_STATIC_LIBS OFF)
	else()
		set(Boost_USE_STATIC_LIBS ON)
	endif()
	find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
endif()
if(Boost_FOUND AND Boost_VERSION GREATER 104900)
        set(OGRE_BOOST_COMPONENTS thread date_time system chrono)
        find_package(Boost COMPONENTS ${OGRE_BOOST_COMPONENTS} QUIET)
endif()

if (Boost_FOUND)
  include_directories(SYSTEM ${Boost_INCLUDE_DIRS})
  link_directories(${Boost_LIBRARY_DIRS})
endif ()
You can copy that code fragment to your CMake project. boost is a critical topic, because there are too many configuration combinations to get it all working at once. The idea is to get rid of boost in future.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Ogre Procedural [v0.2 officially out]

Post by Transporter »

Bugfix (missing namespace) for 75bd728f6ad6:
ogre-procedural.patch
Bugfix for revision 75bd728f6ad6
(592 Bytes) Downloaded 88 times
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

@Transporter : applied, thanks :)

@DanielSefton : you might also be interested in HemisphereUVModifier, applied on a sphere (no need for a spherified box).
It maps the top hemisphere to a UV circle, and the bottom hemisphere to an other UV circle (defaults to both circles being inscribed in the unit rectangle).
OgreProcedural - Procedural Geometry for Ogre3D
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: Ogre Procedural [v0.2 officially out]

Post by Mikachu »

I just released a ready-to-use script interpreter (the binary is windows only). :D

The idea is that you can give it a lua script, and it displays the result on screen.
It will automatically reload the script when modified.
There's also an option to save the results as mesh and texture files.

The goal is to help people prototype with OgreProcedural, or even use the resulting output in their project, without needing to configure their projects for it.

Two sample scripts are provided in the archive to help getting started.

Code: Select all

tb = Procedural.TextureBuffer(1024)
Procedural.Cell(tb):setRegularity(233):setDensity(10):process()
mesh = Procedural.SphereGenerator():setNumRings(8):setRadius(4.0):buildTriangleBuffer()
tests:addTriangleTextureBuffer(mesh, tb)
As the syntax of the scripts is very close to what is in the main API, you can refer to the Documentation to know how to use it.

It's still an early version, but I hope it can already be useful to some :)

EDIT : Visual Studio redistributables aren't included, so if you don't have VS2012 installed, it will complain some dlls are missing. You can get those here.
Last edited by Mikachu on Fri Dec 21, 2012 10:11 am, edited 1 time in total.
OgreProcedural - Procedural Geometry for Ogre3D
Post Reply