Scene graph is not properly updated for rendering cycle update

Only geometry must be change in thread or controls too?

1 Like

Controls cannot be used from another thread unless the features in the control are properly designed for concurrent access (synchronized, volatile, concurrent collections or atomics, etc). Also, you cannot add or remove controls from other threads. In general, unless somebody has said “this method is safe to use from multiple threads” then it is unsafe and you should never use it across threads. This is true not just for jME but for all Java (and really, any language) code.

2 Likes

Other thread = other class?

I think always thread

Thread thread = new Thread();
thread.start();


only main game thread can change 3d controlls capsule…

1 Like

No. Other thread = other thread.

It would be incredibly stupid if you could only modify the scene graph from one CLASS.

2 Likes

I make game class singleton

  public static  GameLevel getInstance() {
        if (instance == null) {
            return null;
        }
        return instance;
  }
  
  public static  GameLevel getInstance(String levelJson) {
        if (instance == null) {
            instance = new GameLevel(levelJson);
        }
        return instance;
  }

And add tasks and futures.

I need use mainApp.enqueue();

or make executor pull?

1 Like

If you are running from a thread that is different than the render thread then: yes. I’m trying really hard to understand why this is so hard for you to understand.

IF YOU ARE RUNNING FROM A DIFFERENT THREAD THAN THE RENDER THREAD THEN YOU CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.

You must use some other means.

3 Likes
  1. class player - not different thread

  2. if i have one player it works, not work if i have 1 > players.

  3. If need modify scene graph only in update method. (3d)

  4. capsule and controls (animation) need setup in update method too.

What better create executor pool or use mainApp.enqueue();

1 Like

Oh my god…

7 Likes

Make this:

  for(String key : players.keySet()){
                
                updatePlayer(players.get(key),tpf);
               //players.get(key).tpfUpdate(); 
              
            }
            
             
        }
        
    }
    
    public void updatePlayer(final Player player, final float tpf) {
        enqueue(new Callable<Void>() {
            public Void call() throws Exception {
                
                player.update(tpf);
                player.tpfUpdate(); 
                
                return null;
            }
        });
    }
    
    
    //
    public static void updatePlayerPosition(JInMessages in){
        if(in.json.get("error") == null){
         
            JSONObject player  =  (JSONObject)in.json.get("player");

            String id          =  (String) player.get("id");
            
            System.out.println("game level update localID " + localPlayerId + " update id " + id);
            instance.players.get(id).setJsonKeys(player);

        }
    }

Work for one player

1 Like

Look… if you are handling your networking on a separate thread then you have stuff on a separate thread. Period. You will need to deal with it.

If you don’t have your networking on a separate thread then you might as well quit now… because your game is going to suck giant elephant balls.

2 Likes

My client server networking
Server side

Client side (same)

custom pool size for in messages and out messages

1 Like

I pack all work with scene graph to futures.

It works for one player.
Now try multiplayer

1 Like

Don’t have more errors with scene graph… Thanks.

1 Like

Lmao a use case and sequence diagram? Do you have a 20 person team working on this?

1 Like

I been programming for 10+ years

1 Like

And…?

1 Like

I can do all one
Long but I can

1 Like

Well yes I assumed as much, but there’s hardly a point to make these diagrams if you don’t have a team larger than like 5 people.

1 Like

For documentation and visual understanding.

https://www.google.ru/search?q=martin+fowler&newwindow=1&source=lnms&tbm=isch&sa=X&ved=0ahUKEwip5p7ZiIfVAhUoM5oKHcA3DxoQ_AUICigB&biw=1215&bih=934#newwindow=1&tbm=isch&q=+design+patterns+uml&imgrc=aoHRR-QX67-1bM:

Work in team with 5 people:

day 1: every go to board and talk about own task.
day 7: git merger.

day 1: every go to board and talk about own task.
day 7: git merger.

repeat.

1 Like

Yeah, doing everything by the book is a valid way of learning, just might be too long one for one’s lifetime. Nothing wrong with reference to Fowler, too. I guess, what @MoffKalast mentioned, that it looks like kinda overkill for a single developer’s project. What I wanted to add is that UML was kinda overestimated as a tool being introduced - and, as it was initially designed with really monstrous workflows such as RUP in mind - especially for small-to-mid sized projects. It was still too technical for managers (and they now have BPML to play with, lol) and not that much quicker to read for coders than the code itself, so…
I mean, sometimes a quick-and-simple focused picture might just suit better than something bigger, but approved by ISO.

2 Likes