makman2 / ce3d Goto Github PK

We need a nice logo at least in the following versions:

• Low resolution ASCII
• High resolution ASCII
• Some real image format

We should integrate it into the doxygen documentation.

For example the Translation::FinalTranslation class could have a more effective function.
Also it's a good idea to use some boost builtin vector and matrix types to generate the transformation matrices (I think they are also more performant than self-written algorithms).

• make a box around every model
• determine this box on vector addition
• redetermine if relevant vector removed (lazy!)
• do this only for complex models
• user doesnt need to know this, this is something done by camera base class in cooperation with renderer base class.

Since the camera and renderer have specialized interfaces from one to another I propose the following directory structure:
src/
output/
____abstract_camera.h/cpp
____abstract_renderer.h/cpp
____console/
______camera/
______renderer/
____opengl/
______camera/
______renderer/
__...

This class serves the efficience improvement for stack based matrix calculations. It should manage the calculation amount.

Every class should be inheritable.

See for this feature:
https://github.com/sakra/cotire

I think we should have two possible modes concerning this:

• Draw at the maximum possible framerate
  Everything that writes something to curses (via Console) will run in this thread.
  If the user changes something it will simply be drawn the next time.
• Draw at a fixed frame rate
  We would probably have one thread drawing the changes model-wise to CURSES and one thread periodically refreshing the console.
  We can use this asynchronous timer for the refresh operations:
  http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tutorial/tuttimer2.html

We would have a mutex that will be locked
a) for refreshing
b) for drawing changes for one model
c) maybe for drawing changes of the whole world through camera position change

Therefore we would not refresh incomplete changes. If the client does not support the given framerate than the real framerate will be lower than the given value in this kind of implementation which is exactly what we want. (And not refresh senselessly since we have the mutex lock.)

The locking mechanism should be on a rather low level so that custom cameras and so on don't have to deal with such things.

Any opinions?

Tests for

• orthogonal transformation
• translation transformation
• scale transformation
• rotation transformation
• custom transformation
• point model
• console
• keyboard thread
• boost extensions
• keyboard state
• world
• renderer
• camera
• console renderer

Quote from an early planning email:
"Achso ganz wichtig: Für CMake brauchen wir für den release (also nicht debug) noch nen #define NDEBUG, das is extrem wichtig für die performance von uBLAS, der Matrix/Vektor bibliothek von boost. Damit werden einige algorithmen bis zu 3x schneller (wenn nich noch schneller)."

For using the API we don't need the cpp files in the documentation. We also dont need references and code browsing.

Let's make a nice representation of our library to the outside!

Title says everything. Testing is easy. Maybe something goes wrong with the color pairs.

use ungetch for this!

Good way to contribute something to codeChecker. Let's implement some of the rules of doc/CC_rules there.

We need a concept for models and materials and how they interact.

Post ideas here! May the discussions begin.

We should add some virtual functions in classes that do nothing, but the user that inherits this class can override them and add some event functionality.
For example:

class LinearCamera
{
  //...

  // Raised when the matrix stack gets updated and calculated.
  // Here the user can perform his own lazy calculations.
  virtual void OnUpdate() const {};
}

And in implementation he can get this "event":

class OrthogonalCamera
{
  //...

  virtual void OnUpdate() const override
  {
     // Any stuff of code...
  }
}

The world's up vector is missing in OrthographicCamera.

This method would be used in OrthogonalDepthProjection and Rotation (when another SetRotation method is implemented)

Since we use variadic templates, we should use the c++0x features everywhere

• Use "using" istead of typedef
• use constexpr where possible for optimizing purposes
• use static_assert for compile time assertions
• use
  const std::vector<...> vi = ...;
  for ( auto i : vi )
• use std ptr's instead of raw ones
• lambdas, ...
• anything else?

http://wiki.apache.org/stdcxx/C++0xCompilerSupport
http://en.wikipedia.org/wiki/C++11

Our data types are long, we have many function declarations that exceed 80 chars.

I pushed a patch that puts the return type and the modifiers before that in an own line.

The constructor of CE3D::Transformation::OrthogonalProjection(Vector const&) is not working, the test for CE3D::OrthographicCamera<> fails before the check RequireVectorEquality at OrthographicCamera::SetLookAt(Vector const&) that invokes the projection constructor.
See test for CE3D::OrthographicCamera<> (in file "/CE3D/test/camera/orthographic_camera_test.cpp").

Currently travis does not run through our project smoothly. Somehow it doesnt compile, see:
https://travis-ci.org/sils1297/CE3D/jobs/29767715
https://travis-ci.org/sils1297/CE3D/jobs/29767716
for more info.

We really should solve this. Especially the compilation agains other versions of gcc/clang is useful

The functions inside this header are used in many tests, so it makes no sense to keep them in the test/transformation/ directory.

Need to implement the viewport transformation (also needed for the cameras).

I have this implemented on the testing branch