Module names for wiki

I have reached the point where its time to move things into modules for the wiki.

I would like to name these modules based off the engine architecture so when something is moved I will know exactly where it should live.

Not sure exactly how to word this so I will just put it as best I can.

How would you categorize the components of jMonkeyEngine and what would you pick as topics for that component?

Ok heres a list of the new moduless.

  • 這是
  • 怎麼了
  • 當你
  • 選擇不
  • 參加

As you can see they are indeed right and match the structure of the engine.

I will use these sub topics in those modules,

  • گرافیک
  • مشارکتها
  • παίρνεις
  • τι λέω;


Lets try this another way,

These are engine components I believe, whats missing, if anything.

  • Rendering
  • Physics
  • Audio
  • Graphics
  • Terrain
  • Networking
  • I/O
  • VR

What engine component do these belong to,

  • Animations = rendering, graphics?
  • Scenes = rendering?
  • Materials = ?
  • Light = rendering?
  • Shadow = rendering?
  • Post-Processor Filters and Effects = rendering?
  • GUI = graphics?
  • Camera = graphics?

indeed hard question.
yes, most problematic is Rendering vs Graphics.

IMO Rendering should go as sub-category of Grahics and contain “Pre/Main/Post render / off-rendering / alpha / depth / aspect ratio / frustrum / etc”
Mainly what is in JME Tests → renderer

Is terrain really an engine component ? That seems really game specific - just curious if this is a relic or an up-to-date decision :slight_smile:

What function do modules serve? If it’s so difficult to categorize documentation topics and pages into modules, perhaps have fewer modules or even just one?

For what it’s worth, here’s how I think about the topics you’ve mentioned:

  • Cameras, lights, shadows, filters, materials, and VR are all “(visual) rendering” in my view of JME.
  • Animations, scenes, meshes, physics, and terrain would then be “modeling”.
  • Networking and GUI might be lumped together under “I/O”.

Of course, that’s not how the software is structured. Perhaps the software and the documentation should have different structures.

All topics are a leaf of some component. What I found when searching is the basic components that make up a game engine are specific to the engine itself. No two engines refer back to the same basic components.

There is some overlap that was obvious like,

  • sound
  • physics
  • I/O

@asser_fahrenholz I am not sure so thats why I ask, what component would it fall under if its not a component itself?

As @oxplay2 says, Rendering vs Graphics. So Graphics should be a component as listed and remove rendering.

A module can be looked at as a Book. The topics are chapters in that book. No two modules/books contain the same topics.

It is extremely subjective as your post helps to illustrate. Try searching on 3d game architecture and see what you get. Everything is specific to the engine itself.

Having one module is what we have now. Everything is lumped into this one module. If all we were going to do is use this one module then what was the use in converting to a modular system in the first place?

So to summarize your thoughts, these are the core components of the jme engine.

  • Sound
  • Rendering
  • Modeling
  • I/O

I really like the detail given in your post but I am surprised you list physics as a topic/chapter rather than a component/book given you have a complete site built around this one subject. That is one thing all engines had listed as a component, physics.

As I mentioned before, I was not sure how to word this properly so maybe this will help clear things up. I know it may seem like a trivial matter, but it is very important to get this right.


That’s a nice analogy, but it doesn’t help us decide how to divide the wiki into modules. Paper publications are split into books for reasons that are irrelevant to a website. Once we understand what modules are for, I suspect the answer to your question will be clear.

You’d know better than I would! Your post indicated a desire to have offsite modules maintained by independent owners. If that’s what modules are for, then perhaps modularization should be based on repositories and/or owners.

That’s an interesting point. Actually my website consists of 2 modules. There’s a “minie-library-tutorial” module that walks you through using the Minie physics library in a JMonkeyEngine game, and then there’s a “ROOT” module for all other aspects of the Minie Project. My thought was that all the “minie-library-tutorial” topics would eventually be shared between my site and the JMonkeyEngine wiki, while the “ROOT” topics would not be shared.

Modules are an organizational method that are intended to hold topics that only apply to the module they live in. When done right, it should be intuitive for a contributor to know where a topic should live. If we match the engine design, this will occur naturally. The wiki will have a certain flow that just feels right. Maybe this will lead to more contributors. This will also help expose where we have holes in content that need to be filled.

For a physics module example, physics related topics and the module itself match a specific design element of the engine. The goal is simplification when adding, removing or editing content. We want the relationship to be obvious.

Take sound. We know this module represents something specific to the engine architecture, thats an easy one.

As was pointed out though, we have rendering and graphics. Is terrain one or the other or should Graphics be all encompassing, including filters, shadow and light? When looking at the engine source, there are terrain, lwgl and gui modules. Do all these have a common element that they spring from? If not then they should be components themselves.

In your use of I/O you lump networking in yet other engines consider that a module all in and of itself. This is the reason I brought this up. Those who are arms deep in the engine guts know best about the core design, not me.

I want to narrow each module down to what makes the most sense, the lowest common denominator so to speak.


  • Graphics
  • Audio
  • Networking
  • Physics
  • GUI
  • Scripting

That sentence looks like a circular definition.

In the case of physics, there’s a very clear division between what’s physics and what isn’t. So clear that the physics code could be moved to a separate repo and released on its own schedule, as I’m doing with Minie. The independent release numbering implies to me that Minie physics, at least, has to be a separate module.

With sound, I don’t think it’s so clear. Sound-related code is found in at least 5 Engine libraries: jme3-core, jme3-jogg, jme3-android, jme3-android-native, and jme3-nifty. If you modularized the documentation based on the Engine architecture, you might wind up with audio documentation in 5 different modules, which wouldn’t make things easy for contributors.

This is a reasonable enough break down, I guess. Even sgold’s comments related to audio aside, there is implementation code spread around but the ‘user’ facing classes are at least all in core.

But I might call “graphics” just “core engine” in our case. Else we need to figure out where to talk about app states, controls, etc… which are not graphics.