Ogre Forums

Maybe you should use this epsilon?

So, just for get about the scaling.
Set the epsilon to 0.0000001 and everything is great.

Are you talking about the new "fast mode" that was added? Heh, I was wondering what that was all about. Thanks for the fix.

No.
The problem is simply the epsilon which is set too high for really low camera speeds.
It works with a topspeed of 3.0f now.
I only noticed because I am working on a scene loader for the Blender exporter where everything is 1 metre/1 unit.

Wolfmanfx wrote:Maybe you should use this epsilon?

Code: Select all

#include <limits>
std::numeric_limits<Ogre:Real>::epsilon;

Looks like a nice universal solution.

Thats the idea

omiter, just started looking at the framework now, nice job!

Why, thank you!

jacmoe wrote:

Wolfmanfx wrote:Maybe you should use this epsilon?

Code: Select all

#include <limits>
std::numeric_limits<Ogre:Real>::epsilon;

Looks like a nice universal solution.

Is this going to be committed?
Or should I file a patch?

Okay, commited.

Oh and by the way, Noman, the Compositors sample makes the browser's shady overlay all white. I don't understand compositors all too well, so I don't know if this is unavoidable for the sample, but this effect remains after the sample ends, so I'm guessing something isn't being cleaned up.

Thanks, Omniter!

Keep up the good work.

Kudos

On gentoo linux I get crashes with the Sinbad example:[codeSampleBrowser: /home/mz/Development/ogre/svn/OgreMain/include/OgreMath.h:578: static T Ogre::Math::Clamp(T, T, T) [with T = float]: Assertion `minval < maxval && "Invalid clamp range"' failed.
][/code]

It only happens when I use the WASD keys to walk around. Anyone else hitting that bug?

Well, I'm guessing the problem originates from somewhere around here:
But I can't see what the problem is...
Math::Abs(yawToGoal) * deltaTime * TURN_SPEED will always be positive...
so yawAtSpeed and yawToGoal will always have the same sign.
If yawToGoal is < 0, then yawAtSpeed will be < 0, so Clamp(yawToGoal, yawAtSpeed, 0) should be fine (min < max).
If yawToGoal is > 0, then yawAtSpeed will be > 0, so Clamp(yawToGoal, 0, yawAtSpeed) should also be fine (min < max).

I don't get your bug, but then again, I'm not running Gentoo. Anyone else having this issue?

Fixed the compositor white screen thing (it wasn't a matter of the compositor framework, but the RTT display was modifying a pass that the framework used internally, changing the texture name. I don't know why a copy of the material isn't used, but oh well).

Also fixed some stop/start/stop/start related crashes, I can't get any others reproducing now.

Just one more crash:
- start instancing demo
- select shadow checkbox
- go back to menu
- select shadow sample
->crash in release mode (didn´t check the debug mode)
So the instancing demo is missing some shadow parameter cleanup?!

Btw: When setting "static geometry" in the instancing demo some of the space ships still disappear at the top of the stack...

xad

Hi! I noticed the following apparent bug in the Dynamic Texturing (DynTex) sample as available from the sample browser in Version 1.7.1. When I compiled OGRE 1.7.1 from the source using Visual Studio 2008 under Windows 7 Ultimate, the frost was temporarily cleaned in wrong places, several hundred pixels above the mouse cursor (with the left button down and the mouse being moved around). When I compiled OGRE 1.7.1 from the same source using Visual Studio 2008 under Windows XP Professional on another computer, the frost was cleaned correctly in the area immediately under the mouse cursor. If this is not the right forum to report suspected bugs for discussion, please let me know which one's right.

I can't think of a better place to report this problem, but I honestly can't diagnose it. I don't see why it would happen under one OS and not another.

I ran the Windows 7 version one more time and realized that the whole frost area is shifted half a screen up relative to the bird there, so only half of the screen is getting covered with the frost. So the mouse position is read in the right place, but the effect of the action is displayed in a wrong place.

I'm using the same OS and compiler as you are. I tried with the 1.7.1 SDK, and there was no problem. You said you compiled OGRE from source?

This is correct. I compiled from source, then ran the sample browser. I started the penguin-frost sample from the sample browser.

Okay, that's just weird. I compared the new source and the SDK code, and it's exactly the same, except that Ogre::uint8 changed to uint.

Hi, everyone,

over the last year, I created a SSAO sample based on the sample browser as my bachelor's project. (sources and a preliminary documentation can be found at https://bitbucket.org/simonwallner/ogre-ssao-sample and https://bitbucket.org/simonwallner/ssao ... x/ssao.pdf, official announcement to follow in the next days.)

Now I wonder, if it was possible to distribute my compiled version of my sample separately from the ogre core, so that users can just download the small sample and start it with an existing version of the sample browser, without further configuration?

kind regards,
Simon

In principle, yes, but your compiler and build settings would have to match exactly with those used to build the Ogre version your users have. Simplest way would be to use the SDK version of Ogre for your compiler and build the sample with it; then everyone with the same compiler who uses the SDK could run your sample.