Wiki scrub

Documentation
1

I have been scrubbing the wiki of converting .blend files using the SDK or BinaryExporter .

Its turned out to be a arduous task but I will complete it soon, days so far and more to go.

At the same time I have been implementing some new things and removing stale items. ALOT of stale items.

I figure I should go ahead and give insight on what I want to do after scrubbing the .blend stuff.

We need to make the official jme wiki agnostic of using the SDK. Towards that goal, I plan to move the SDK part to a new repository that will work exactly as the wiki does now and rewrite things that rely on it now in the official engine wiki.

I also want to make the tutorials agnostic of SDK and gear them towards using gradle instead.

This doesn’t mean I want to remove all mentions of the SDK, I just want to make it so that if the SDK has problems with developement, the engine wiki is unaffected and users are not affected like is going on now. I would also like to add links to the jmonkeybuilder but I am not sure @javasabr is still developing it. Not heard from him in awhile on the forum.

Another problem is Ogre. It is no longer viable for use with the engine IMO since its now a pay to use script, or was last I checked, and the free script the engine is built around no longer works with blender 2.8. I shall make a small caveat to this statement in that I have not actually tried to use Ogre with 2.8+ yet, just my researching lead me to believe this is the case.

This would mean that we would need to update the models in test-data since they are heavily reliant on ogre. We need more gltf examples.

I want to implement versioning to the wiki so it can stay inline with the engine. This would allow the current wiki to stay as it is now so I could move forward with the things I mentioned above.

This would take place a little at a time over the next year since this is pretty much a solo adventure and a huge amount of work.

Anyway, input will be listened to so fire way.

11 Likes
2

Just want to say that the wiki is vital to everyone. We appreciate your efforts looking after its state @mitm .

5 Likes
3

i agree, SDK is nice and helpfull, but wiki should not require SDK actions.

Well, if Ogre will not work for Blender 2.8+ in future, then seems like Ogre should be marked as deprecated

This would mean that we would need to update the models in test-data since they are heavily reliant on ogre. We need more gltf examples.

IMO test-data should have NEW nice models, not ugly ones we have. For example high quality free ones(best if CC0) from webpages like Free 3D models - Sketchfab

for example:

(3k triangles , CC Attribution)
or character:

(14k tris , CC Attribution)
Just give notes about authors, and we have very nice models for test-data. (please note as i know test-data anyway contains some wrong licensed models as i heard, so its anyway better it could change it).

It require JME Tests update models OFC that can take time.

1 Like
4

Yes exactly. Modern assets like these will kick up interest alot. I am only familiar with the pre 2.8 blender and gltf so I have to basically relearn this pipeline.

I am nearing the end of my spring boot integrations with simethereal so once thats all done I will be hard at asset creation.

I also want to segregate blender use within the wiki. Basically delegate it to use with how to’s.

Using the wiki more for emphasis on the engine features and how to implement them.

2 Likes
5

I am only familiar with the pre 2.8 blender and gltf so I have to basically relearn this pipeline.

2.8 is not that much different.

UI changed just a lot, but actions stay the same.

New things is Eevee (real time PBR preview) so no need use Cycles render preview that take time to see it properly, now you can see PBR material in real-time there. Thats very cool. you can paint using this preview, for example “metallicTexture” and see how model in paint place become more “metallic” without f12 or other things.

Also they changed a SceneGraph a little. there are “containers” alike.

If you will have questions “how to - in blender 2.8+” just ask me.

BTW. i generate even normalMap in blender, but not from high/low poly difference, but just from bumpMap, much easier :slight_smile:

6

I second @jayfella 's comment that wiki work is important work.

Existing Ogre models, such as Sinbad and Ninja (which were presumably created with Blender pre-2.8) are fine. So there’s no urgency to update jme3-testdata.

I also don’t see a need to deprecate JME’s Ogre loader in the jme3-plugins library. It seems to work, provided you use Blender 2.79. The issue with Ogre is that it’s not a viable asset pipeline for new development. For the future, we should promote the glTF asset pipeline as its replacement. (How convenient that glTF export is built into Blender 2.8!)

We need to strongly discourage use of the Blender loader in the jme3-blender library. That library hasn’t been actively maintained in years, and it’s a major source of issues (and trouble-shooting requests). Deprecate it, delete it, and remove it from the wiki please.

3 Likes
7

Thats what I am scrubbing currently. Part of that will be solved by moving the SDK to its own wiki since thats where most of the information about it is.

1 Like
8

This is really great. I’m happy someone has taken up this job because documentation is so important and so often neglected.

Thanks for doing this!!!

Edit: also once we’ve scrubbed mentions of the .blend plugin from normal documentation… maybe we can start the process of moving it out of the engine into jme-contrib.

3 Likes
9

Hi @mitm,

I stopped working on jMB a long time ago.

10

For the models that were mentioned, I do agree that they should be updated, but it might be nice to create an additional dependency. Something like jme-testdata-adv or something. It doesn’t even have to be official, just something people can reference that has modern PBR models with example classes.

The lightprobe for example in testdata - is quite yellow. I have made my own to make it more white. I do think that the examples need a new modern spin to them with stuff you can use as placeholders.

It might be that I end up doing these myself, though this is another topic, and would require some discussion if it were to be “official” per se.

11

Nehon gave me a handful of default light probes that we included in spix. It was nice for selecting different kinds of generic indoor/outdoor scenes. I will confirm the licensing and maybe we can include some of these somewhere.

12

Sorry to hear that. Its a demanding task to write theses programs by ones self.

13

I think people are falling into the same trap the wiki has been in where you try to accommodate those on the previous version while at the same time adding new content.

I notice that no other projects do that myself. When something gets stale to the point of no longer being viable, like the Ogre for example, it gets fixed, replaced or removed when a new version is cut.

The Ogre stuff should be on the chopping block because its leading new users down a dead end unless someone can come up with a fix.

14

I don’t agree, it’s not too hard, I have stopped only by community size reason.

1 Like
15

The size of the community is large. Being able to produce something that changes someones workflow is very difficult indeed.

Sometimes just because something “should” work - doesn’t mean it does. That’s just the life of a developer, I guess. The only real way to know if something will work or not is to prototype. Sometimes you win, sometimes you don’t. Sometimes it “should work” and doesn’t. Sometimes it has no reason to be popular at all and “is”. C’est la vie.

16

I am not certain but I took that to mean the numbers of people using his SDK wasn’t large enough to justify the effort, not a swipe at jme.

17

Think I am done with .blend scrub and removing alot of stale content.

On master, 155 files have changed and there have been 1,953 additions and 16,157 deletions .

The next stage will be to implement versioning so I can get real bloody. Heads are gonna roll.

2 Likes
18

In essence, from now on, official wiki will be agnostic of file types for conversion. Instead, I consolidated all content into separate detailed pages on conversion and now all links point to the features page for the engine so everything starts from the same jump off point.

https://wiki.jmonkeyengine.org/jme3/features.html#supported-external-file-types

There were many things pointing to pages all over the place with similar content.

Much easier to track now.

3 Likes
19

Thank you for all that hard work.

  • The conversion page says that the Ogre formats are soon to be discontinued. I thought it was .blend for which support is soon to be discontinued.

Also, I suggest the following additions:

  • .bmp is a supported format for texture assets.
  • .fbx is a supported format for 3D-model assets.
  • .ani, .cur, and .ico are supported formats for cursor assets.
1 Like
20

It seems ogre is also kind of on the way out… no strong reason to remove it yet but it’s apparently for pay in new Blender and ultimately a dead-end ancient format.

Unlike .blend which doesn’t work well even when it is working and is a pain to support in general… and needs to go ASAP into its own jme-contrib module.