Shadow pass and Vertex count

So I was wondering if someone could shed some light on this issue.  Maybe it’s not an issue at all, but just what is supposed to happen…

It seems that my vertices are being (roughly) quadrupled when a shadow pass is used.  Here are two pics showing what I mean.

The shadow objects are low-polys that are culled, as a pose to using the visible higher-poly objects.

The only change I made to the two renderings was to setRenderShadow( false )

I would really like to continue using dynamic shadowing but am feeling like I may have to resort to a flattened geometry approach  :expressionless:

I am no expert, but I think ShadowPass is another render pass, and thus, it needs to process everything in the scene again, and not only that, but create the shadow volumes. Maybe the bad part is the drop in frame rate…  :expressionless:

Actually, the drop in frame rate is even worse than what is shown in the pics.  By just turning shadow rendering off, there is still a wasted pass for each frame due to the passManager update.  SO the real frame-rate is closer to 300fps  :|.  Which is why with such simple shadowing requirements I am just considering flattened geometry, but thats just kinda cheesy…

There is no wasted pass, the update pass does not render the objects to the scene. For this simple application I think just putting a darkened circle primitive under each ball will do.

Yeah, but that severely limits my lighting and shadowing options in the future. :slight_smile:

On a side note, changing the blend type to modulative seems to reduce the amount of vertices added but the shadows lighten instead of darken.

I am still trying to understand what vertices are being added, I thought using the stencil buffer didn't need actual meshes rather its more of an overlay.  Please correct me if I am wrong here.

if all shadows are left in there are approx 27,000 vertices

if I remove the table shadows, there are around 26,000

if I remove the ball shadows there are approx 25,000 vertices

if I remove all shadows there are only 8000 vertices

So just putting circles around under the balls still doesn't get me anywhere.  What happens when its actually time to add some player models??

You may be using it incorrectly.  Another forum poster recently posted an example where he was attaching the scene to the pass (which renders the scene) but also calling render on the objects outside as well.

ie, this bad pseudocode:



(Has the effect of drawing your scene twice.)

So you're have 8000 verticles for a few balls and a board? You could try using less detailed balls for the shadow volumes and see if it helps.

The shadow objects are low-polys that are culled, as a pose to using the visible higher-poly objects.
from the top post.  Only around 1000 vertices are being shadowed as it is, before doing that my frame-rate was less than 10fps :)

Renanse: No, I don't think so here is my update method

    protected void update( float interpolation ) {
        StringBuffer tempBuffer = new StringBuffer();
        StringBuffer updateBuffer = new StringBuffer( 30 );
        /** Recalculate the framerate. */
        /** Update tpf to time per frame according to the Timer. */
        tpf = timer.getTimePerFrame();
        // Execute updateQueue item
        updateBuffer.setLength( 0 );
        updateBuffer.append( "FPS: " ).append( (int) timer.getFrameRate() ).append(
                " - " );
        updateBuffer.append( display.getRenderer().getStatistics( tempBuffer ) );
        /** Send the fps to our fps bar at the bottom. */
        fps.print( updateBuffer );
        // Do physics update
        if ( !pause ) {
            float tickPerFrame = this.tpf;
            if ( tickPerFrame > 0.2 || Float.isNaN( tpf ) ) {
                Logger.getLogger( PhysicsSpace.LOGGER_NAME ).warning( "Maximum physics update interval is 0.2 seconds - capped." );
                tickPerFrame = 0.2f;
            physicsSpace.update( tickPerFrame * physicsSpeed );
        input.update( tpf );
        if ( !pause ) {
            /** Update controllers/render states/transforms/bounds for rootNode. */
            rootNode.updateGeometricState( tpf, true );
            // fpsNode.updateGeometricState(tpf, true);
            pManager.updatePasses( tpf );

        if ( firstFrame ) {
            // drawing and calculating the first frame usually takes longer than the rest
            // to avoid a rushing simulation we reset the timer
            firstFrame = false;

and here is my render method

    protected void render( float interpolation ) {
        Renderer renderer = display.getRenderer();
        /** Reset display's tracking information for number of triangles/vertexes */
        /** Clears the previously rendered information. */
        // Execute renderQueue item
//        renderer.draw( rootNode );
//        renderer.draw( fpsNode );
        pManager.renderPasses( renderer );
        doDebug( renderer );

and here is my initialization code

    protected void simpleInitGame() {
        DisplaySystem display = DisplaySystem.getDisplaySystem();
        // set the camera little bit backwards.
        cam.setLocation( new Vector3f( 0, 80, 0 ) );

        balls.createBalls( true, 0 );
        Node ballNode = new Node();
        ballNode.attachChild( balls.getBalls( 0 ) );
        rootNode.attachChild( ballNode );
        for ( int i=0; i<getDriver().getNumberOfBalls(); ++i ) {
            sPass.addOccluder( balls.getShadowBall( 0, i ) );
        rootNode.attachChild( table.getPhysicsTable() );
        sPass.addOccluder( table.getShadowTable() );
        cameraInputHandler = new FirstPersonHandler( cam, 50, 1 );
        input.addToAttachedHandlers( cameraInputHandler );
        control.setPlayControls( input );

        rootNode.updateGeometricState( 0, true );
        rPass.add( fpsNode );
        sPass.add( rootNode );

I am starting to think that this is just the way this shadow pass technique works, the demo appears to have the same behavior...

With shadows average of 65,000 points
without shadows average of 11,000 points

One help is that in jME 2.0, if your card supports double sided stencils, it uses half the number of draw calls.  As for the shadow test, it uses 3 shadow casting lights (so 3x the shadow volumes) and it uses additive mode by default, which means the scene is redrawn 1x for each light.

As for the shadow test, it uses 3 shadow casting lights (so 3x the shadow volumes) and it uses additive mode by default, which means the scene is redrawn 1x for each light.

That makes sense, but I am only using one shadow light, so I can't understand why the vertices are not just doubled....

As for double sided stenciling thats a great extension, I notice here,M1
that it is supported under Opengl 1.1 and here the specification was released jan 2003.

So how new must an opengl renderer be to support this extension??  Would say an MX card do it??

Honestly, I don't know.  I'd say it was probably more about drivers than hardware, but that could be wrong.