Then create a smaller test case that exhibits the problem.
This isn’t just for us… 99 times out of 100 your simpler test case will work just fine. Then you can track your own bug by finding the difference. Seeing little peephole views of your code that may or may not be relevant (if you knew what was exactly relevant then you’d have already solved the problem, eh?) is often just a waste of time.
I’d be glad to wrap up the whole project and post it somewhere if there is a place where I could send it to.
The simplest case I can think of is to set the Local Translation of the Emitter to the same as an object that I can see, and I can see the object but not the emitter, even when I don’t attach the object to the root node.
A simple test case would be one class that sets up a particle emitter and two viewports.
“But I don’t want to do all of that work?”
Yes, well, we don’t want to decipher a whole project just to find the one possible needle in a haystack. Never mind the fact that this is just standard debugging if you are trying to isolate a problem… and if it does turn out to be an engine bug then you have provided a nice self-contained test case.
Else, I can tell you that the group of folks that are willing to download a whole project and sift through it is way smaller than the number of folks who could/would actually provide help.
The ‘simple’ case (one emitter with 2 viewports) works. The larger project involves shadow mapping, terrain blending, creation of alpha maps, use of different materials, terrain quads and lod controls, physics etc.
Trying to work out which of these to or not to put in a “simple test case” is not as “simple” as you make out, but I’ll see what I can do.
But you see, this is the point. Now you are well positioned to figure out the difference that breaks it. Start adding likely culprits one by one until it breaks.
I don’t want to spoil the ending but often times it has nothing to do with JME and it’s something you’ve misplaced in your own code. Not always… but enough times that it’s better if you get used to this process of finding bugs.
I’m sure it is something to do with me, but often another set of eyes picks up something straight away.
Anyway, I’ll soldier on…
Where is the origin of a Particle Emitter ? If I set a local translation of say(0,0,0), what point in the emitter does it set to that value ?
How do I make an emitter visible at high distances from the camera, say 500000 WU ?
Unless you adjust the camera frustum, 500000 WU is going to be well past the far clip plane. Why do you want to visualize particles at that distance? A little more information on what exactly you’re trying to accomplish would be helpful.
Hi Daniel,
I’m doing a ‘planetary explorer’ game with large terrain and I want to simulate volcanoes that can be seen from a far distance. The far clip plane is set to well past the volcanoes position, but unless I get up very close I can’t see the particle emitter.
You should put together a single class test case with that setup.
…then when it works you can figure out what else might be wrong.
Ok, that makes sense… unfortunately I don’t know what would cause that behavior, but in general I’d say that world coordinates at huge scales like that are best avoided. Theoretically it “should work,” but often it seems like people encounter more trouble (especially with physics sim - not sure if you have that or are planning it) than usual when dealing with huge coordinates. I’d suggest that you consider scaling things down a bit, or using some sleight-of-hand to achieve the volcanic particle effects so that you’re not actually counting on the engine rendering things that are 500k world units away. A single class test case would also probably do you a lot of good.
That’s true, floating point starts to lose last decimal precision as early as 65,000 units.
For “far” terrain, it’s best to treat that in a completely different scale. Render the far terrain at 1:100 or 1:1000 scale.