ogrecave / ogre-procedural Goto Github PK

Providing a "FindProcedural" macro would make configuring a project for 
ogre-procedural easier.

Currently, samples use the install target to copy Ogre files.
Ideally we would use configure instead, so install would be reserved to 
creating a sdk directory.
Media files and cfg files would be versionned into Ogre-Procedural, and only 
required dlls would get copied.

Right now, every primitive is oriented in a specific manner (Y-axis is the "up" 
vector for primitives such as cylinder and cones..)
It would be useful to be able to scale/orient/translate primitives inside the 
mesh. 
Of course, this would not be a replacement for Ogre's scene graph hierarchy, 
but something useful when working inside a mesh.

Once a file format will be defined, a possible feature could be automatic 
caching of resulting meshes. The goal would be of course to speed up mesh 
generation when it has already been done, and would be especially useful for 
long operations, such as CSG.
The user should be able to freely enable/disable it globally or per mesh, or 
even let the system decide by itself (based on the quantity of cache mem 
available and the complexity of mesh generation).

Put a lot of comments in API code and output a Doxygen guide.

For this purpose, TriangleBuffer should do something closer to what is done 
with ManualObject : calls to normal(), textureCoord() should only refer to the 
last added vertex, and shouldn't add a new vertex.

Right now, the only way to customize UV generation is uTile and vTile.
A cool feature would be the ability use a texture atlas, targetting only a part 
of the texture, for example.

Just another way to init a generator if one doesn't want to use the classic 
"setSizeX()"

It would be nice to be able to redistribute a precompiled and ready to use sdk.
A CMake install target could copy everything needed to a sdk folder, as Ogre3D 
already does.
Next step would be a 'findOgreProcedural.cmake'...

Being able to build a "middle shape" betweeen several shapes would be great for 
extrusion.
It should not be used when a simple scale or rotate is needed (for that, a 
simple modifier on extruder would be enough).

Test it with ubuntu!

Create a generator that takes a shape and a path and outputs a mesh

These property should be settable, either for a given segment or group of 
segements, or for the whole path :
- Shape orientation
- Scale
- Rotation around path axis

Rather than a raw crash, generators should provide assertion errors when a 
parameter is wrong.

This would allow the display of shapes and paths, which is useful for debugging 
user code or OgreProcedural itself

Compiling and running sample should be optionnal in CMake.

Implement ProceduralRoundBoxGenerator

Paths and SimpleSpline are quite similar in their functionality, so conversion 
is easy.

If a point of seg1 lies on a segment of seg2, union of seg1 and seg2 does not 
work.

Whenever it's possible, estimateVertexCount and estimateIndexCount shall be 
used, to reduce buffer reallocation.

Using BezierPath in an extruder can produce visual bugs, especially when 
working with tight angles. A workaround should be found to make it look 
visually OK.

The user has to say whether the outside of its shape is on the left or on the 
right side.
When the shape is closed, it's actually possible to determine that 
programmatically...

Some people think it's a good idea...
First step would be to create an uniformized software vertices/indices buffer 
and have every mesh generator output to it.

Right now, the samples are only included in the full source release.
It would be good to include sample in precompiled SDKs, even if kept at a 
source level.

It is quite obvious that users need to be able to procedurally generate terrain.
Different methods of generation shall be provided:
- Random/perlin noise
- Fractal
- User-provided functor
- Pseudo-random based on tendencies (user defines where is it more or less 
mountainous...)

It shouldn't be compulsory to name the output mesh, instead, you may just want 
to get an auto generated name.

Same as 3D CSG, but in 2D.
Might be easier to implement.

A file format which could define procedural meshes could be great in order to 
move mesh description away from code.
However, once this format is defined, it should always be in sync with features 
available from plain code.

Ogre's paging system really seams powerfull and extensible.
As OgreProcedural may take quite some time to generate a big scene, paging 
(with background generation) seems like the perfect tool for the job.

Besides the Catmull-Rom mode, the user should have several ways to define 
spline tangents:
- Custom tangents with Bezier algorithm
- Smooth tangents
- Defined angle
...

The user should also be able to mix up several modes in the same spline.

Sometimes the normals are reversed.

What steps will reproduce the problem?
1. Generate IcoSphere by generator
2. Apply material with texture
3. See chaos !

What is the expected output? What do you see instead?
http://img845.imageshack.us/img845/6131/tmp1.png
Both poles seem to be affected.

What version of the product are you using? On what operating system?
0.1, WinXP, Ogre 1.7.2 ( Mogre )


Everything other seems to be fine, just the UV generated for Ico is not correct.

Extrusion will need triangulation in order to generate caps on non-closed 
paths....
Here is a a good description of a constrained delaunay triangulation, that we 
could use : http://www.geom.uiuc.edu/~samuelp/del_project.html

Right now, triangulator has a special layout.
It should be like any other mesh generator.

The idea is to extend extrusion to inter-connected multiple paths, such as an 
exit from a highway, if you model the highway using extrusion.
This feature is still highly theoric, ie I'm not sure there's a nice solution 
to do that. Anyway, it would be very powerful if it worked...

Solution : duplicate vertices around u=0.0 line

[deleted issue]

One cool feature would be to be able to project something (path, mesh?) on a 
plane or a terrain.
That would enable the creation of roads, for example.

In every configuration... of course

The sample crashes on exit

Testing new features shall not be done in samples, because it produces 
instability.
An optionnal "test" subproject would be better...

When modelling a city, you often have repeating elements, such as pillars under 
a bridge, or lights along a road.
A repeater would adress this need..

Someone on the forum argued it is a big overhead... got to check if we can 
easily switch it on/off.

Revolution and extrusion will need this...
Required features:
- create a shape/path from points
- automatically determine wheter it's closed or not
- add the ability to specify what is "inside" or "outside"
- create a bezier generator
- create many simple shapes/paths generators, such as circle, square, line...

UV texture has some quirks at some places...

Here's a small patch that fixes a few problems I had:
* Added support for generating the mesh into a specific resource group.
* ManualObject is now unnamed and cleaned up after generating the mesh.

It's still the most popular IDE out there...

The idea is simply to generate a mesh from a shape rotated 360° around an axis.

Inspire on what has been done for Ogre.
It seems it's not easily possible to support PCH for something else than VS...

Including thesse scripts would allow more simplicity in ogre-procedural's cmake 
scripts...