Ogre Procedural [v0.2 officially out]
-
- 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]
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.
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.
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
Probably, since the particularity of triplanar texturing is to look good everywhere, whatever the geometry , and since it's now integrated with RTSS, it would be easy to use..PhilipLB wrote:Maybe some triplanar texturing on a sphere wouldn't look too bad?
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
-
- 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]
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.
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.
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
Yes, it would be possible by generating 3 UV sets, it would even work with fixed function...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.
But it would just skip the runtime UV generation, not the triple texture lookup, even with a single texture.
OgreProcedural - Procedural Geometry for Ogre3D
-
- Gnome
- Posts: 334
- Joined: Thu Jun 28, 2007 2:12 pm
- Location: Brazil
- x 5
- Contact:
Re: Ogre Procedural [v0.2 officially out]
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
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
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
@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.
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
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Ogre Procedural [v0.2 officially out]
Based on 1f55db062f2c:
I'll take care of issue 128 next week.
- 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.)
I'll take care of issue 128 next week.
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Ogre Procedural [v0.2 officially out]
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
- 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.
- Maybe it's helpful to create a resource loader class to load CAD data files and build the objects by ogre procedural.
-
- Gnoblar
- Posts: 18
- Joined: Tue Aug 09, 2011 3:20 pm
Re: Ogre Procedural [v0.2 officially out]
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
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
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
@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.
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
- 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]
Thanks for those changes! Cylinder caps are much better now. Would you mind posting a snippet which shows how to use the spherify modifier?
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Ogre Procedural [v0.2 officially out]
Bug in revision fe44de8e2ff4:
mCenter and mRadius are not defined in ProceduralMeshModifiers.h!
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
- Restore ProceduralMeshModifiers.cpp
- Fix help after renaming Rectangle to RectangleTexture
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
Oops, there's something I forgot to commit.Transporter wrote:mCenter and mRadius are not defined in ProceduralMeshModifiers.h!
It's fixed now.
Sure.DanielSefton wrote:Would you mind posting a snippet which shows how to use the spherify modifier?
Code: Select all
TriangleBuffer tb = Procedural::BoxGenerator().setNumSegX(10).setNumSegY(10).setNumSegZ(10).buildTriangleBuffer();
Procedural::SpherifyModifier().setInputTriangleBuffer(tb).modify();
tb.transformToMesh("sphere");
The UV modifiers I'll implement will address this issue.
OgreProcedural - Procedural Geometry for Ogre3D
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Ogre Procedural [v0.2 officially out]
You also forgot to update the help after renaming Rectangle to RectangleTexture.Mikachu wrote:Oops, there's something I forgot to commit.
It's fixed now.
- 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]
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?
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 (122.04 KiB) Viewed 3489 times
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
Do you mean that it should look like the singularity in normal sphere?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?
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
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: Ogre Procedural [v0.2 officially out]
- 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
-
- Gnoblar
- Posts: 8
- Joined: Wed Sep 05, 2012 11:07 am
Re: Ogre Procedural [v0.2 officially out]
Hi,@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?
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
-
- Gnoblar
- Posts: 1
- Joined: Sun Dec 09, 2012 4:47 pm
Re: Ogre Procedural [v0.2 officially out]
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
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.
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;
}
}
}
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.
-
- Halfling
- Posts: 41
- Joined: Sat Dec 01, 2012 12:47 am
Re: must manually fix mingw linking problems to boost
----- 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?
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?
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
@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...
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
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
Re: must manually fix mingw linking problems to boost
There is a boost detection included in CMake script of Ogre-Procedural. You just have to set BOOST_ROOT:hall wrote:Is there anything I should add to CMake or CMakeLists.txt to make this work automatically all of the time?
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 ()
-
- Minaton
- Posts: 933
- Joined: Mon Mar 05, 2012 11:37 am
- Location: Germany
- x 110
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
@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).
@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
- Mikachu
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: Ogre Procedural [v0.2 officially out]
I just released a ready-to-use script interpreter (the binary is windows only).
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.
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.
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)
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