Inconsistent transparents

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
Nicker
Gnoblar
Posts: 6
Joined: Tue Jul 23, 2013 11:34 am

Inconsistent transparents

Post by Nicker »

When the depth of two or more transparents is the same, their sort order is random.
Any ideas in how to solve this ?

Code: Select all

 // Different renderables, sort by depth
	Real adepth = a.renderable->getSquaredViewDepth(camera);
	Real bdepth = b.renderable->getSquaredViewDepth(camera);
	if (Math::RealEqual(adepth, bdepth))
	{
		// Must return deterministic result, doesn't matter what
		return a.pass < b.pass; //THIS IS THE ISSUE
	}
	else
	{
		// Sort DESCENDING by depth (i.e. far objects first)
		return (adepth > bdepth);
	}
Link to source: https://bitbucket.org/sinbad/ogre/src/d ... ping.h-178

In this line

Code: Select all

	return a.pass < b.pass; //THIS IS THE ISSUE
Result may vary for two renderables, since the comparison is based on the Random Memory Addresses of the passes.
paroj
OGRE Team Member
OGRE Team Member
Posts: 1994
Joined: Sun Mar 30, 2014 2:51 pm
x 1074
Contact:

Re: Inconsistent transparents

Post by paroj »

you can see one possible solution here:
https://bitbucket.org/sinbad/ogre/pull- ... ping.hT178

however it requires tracking the creation number for each object which again might be random in a multi-threaded environment.

Maybe you can describe which underlying issue you want to solve here.
Nicker
Gnoblar
Posts: 6
Joined: Tue Jul 23, 2013 11:34 am

Re: Inconsistent transparents

Post by Nicker »

Yes, this is my PR, :wink:
Alas, declined.

If it's bug, at least let it be a consistent one and not random.

In my case I have a ParticleFX effect assembled from two passes.
Both the passes are transparent and their respective renderables have the same position where eventually they get exactly the same depth.
so the code above provides random results for each run, or for a single run when using a multi process environment.
It is unlikely that a multi threaded environment will be an issue here since passes creation is adjacent for a specific, technique/effect.

It will not solve the issue, but if no solution will be merged to Ogre I'll find something more deterministic such as Pass::getHash so we'll live with the evil we know,
Post Reply