A state I'm familiar with.  "We've done the fun parts now we need to do the hard parts... so we must be halfway done!"

...only at least I never felt I was halfway done.

I wish them luck as it looks like it might be cool.  The pessimist in me tries not to think too hard about the fact that they are at exactly the same place most game dev efforts fail.  Keep an eye on them.

Hi, thanks for the interest.  You can find more details in other posts but the short story is that 5 years ago my wife was diagnosed with brain tumors.  Since then she'd had a few surgeries, radiation, chemo, etc... she's back on chemo now.  She can't drive so I'm responsible for driving her to all of her appointments, the kids to all of their things, etc. plus working a full time job, doing much of the 'keeping the house going' stuff and so on.

My non-paying work time went from 20-30 hours a week to now it's about 4 hours a week on average.  Every now and then I take some time off work to move things along but obviously development is MUCH slower now.

Nice.  A little mean... but funny.

You are greatly overestimating the amount of work it would take to foil such a system.

I cannot think of a single approach that would be easier for me to write than it would be to defeat.  Every system I think of is trivially defeated by anyone even remotely experienced with coding.  It only takes one person.

So it's totally not worth the effort.

For single player, it obviously can't be done.  The position has to be known somewhere.

For client server, every position of every object would have to be obfuscated per client.  The only real way to do it would be to keep all positions relative to the player.  Even the random offset you mention only works until you pin against a know location.  For example, one need only decide a particular landmark is coordinate X and then it doesn't matter if your coordinates are real or not because they can be made consistent.

...but really now I don't even know why we want to do this.  Because even relative positions would suffer from this locally.  Once you have points of reference, the hack could convert places to world coordinates again.

Yeah, map and compass.  Maybe if you get a sextant or something then you can pinpoint better positions.

That was the plan, anyway.

Would there be any passive coordinate obfuscation? And, concerning mods, would there be anything preventing a user from modding their client with a coordinate display when the server doesn't authorize it? I'm currently in a situation where, while I want to get rid of coordinates on a server I'm developing, it would give cheaters an increasingly unfair advantage since they can basically keep track of everything's location like it's just another Tuesday.

This would be very difficult to obfuscate and not really worth the trouble, I think.

Yeah, map and compass.  Maybe if you get a sextant or something then you can pinpoint better positions.

That was the plan, anyway.

Before this, I was convinced that half the features did nothing or just broke the tree. xD

Heheh. 

Thanks for the timely response, as usual.

Time for today's update and ?'s post. I've created material for every part of the editor at this point


Now for questions.


Branches/roots
So, first off, I want to ask: Is it a safe bet to just merge the branches and roots sections? The tabs seem identical, aside from the presets.

I guess the settings are similar but one goes down and the other up.  Often times you want different root settings than branch settings which is why they are separate.

Next is another suffix question. I saw the parameters "Segment Variation (*)" and "Taper (*)". I see that suffix around in a lot of places. What does it represent?

I don't remember exactly.  More examples of where I used it might help but I suspect it's a "non-unit" or maybe indicating a multiplier.

I'm assuming "Twist (rads)" means in radians, but confirmation never hurts.

Yes, radians.  So 3.14159... is 180 degrees.

"Tip joint" is something I want to clarify on as well. This parameter converts a side joint from each node into a tip joint to serve as a continuation of the main branch, correct?

In a regular L-system, you have great flexibility over how you replicate and morph things at each level.  I limited this greatly to produce a simpler interface.  But just branching, branching, branching makes it hard to do things like pine trees and such that essentially replicate the whole tree at each level.  The tip joint is sort of a compromise.  So rather than _just_ branching out when you reach the tip, the root trunk will get an additional tip joint that replicates the tree but shrunk down and with some additional tweaks (like tip rotation).  It's kind of like planting a smaller version of the tree at the top of the tree... and doing that again a few times.  I think I limit it or maybe I let the user limit it?  I don't have the tool up so I can't say for sure.

But it lets you have tall trees.  Adding a little rotation gives you some variation. 

"Tip rotation (rads)" is a function that exclusively rotates joints branching from a tip joint, is that accurate?

Yeah, it rotates each new tip by that amount.

You can almost replicate something similar to what Mythruna's 'scrub' trees (the really tall but sparse ones) by having a branch factor of 2 or 3 and turning on the tip joint with very little scaling but about 90 degrees tip rotation.

LOD
LOD is something I'm gonna need lots of help with. It seems very... finicky and generally hard to understand sometimes.  I messed with some of those settings and I think an unexperienced user that isn't paying attention would wreck their tree editing experience here. The abbreviation stands for Limit Of Detection, though, correct? Does this affect the tree mesh like the other settings or no? I ask because it doesn't seem to affect the triangle count

The Distance parameter seems to create a ring around the tree where it will be displayed in full detail, where getting to close to the tree will cause it to enter low poly mode if you set it high enough. That is, at least, how it behaves in the "highest" subtab. What do each of the subtabs apply to?

I understand what the mesh type parameters do to some extent, but I'm not sure how to describe the features of normal and flat poly meshes.  Do normal meshes simply use triangles, while flat poly meshes always pair their triangles into quadrilaterals?

LOD stands for "level of detail".  It's away of simplifying rendering if you are farther away.  Each level has a distance range within which it is in effect.

At each range you can adjust settings that help control how many triangles are rendered.  I don't remember what all of the settings are but for the regular hi-poly mesh then there should be a way to control the depth of branching and maybe something else to control the quality of the mesh like number of radials or something.  I don't remember.

There is also the flat polygon version which renders a _greatly_ simplified version of the tree using a shader trick.  Basically, instead of rendering a round branch section (lots of triangles) it just renders a quad that always orients to the camera.  From far away it still looks 3D because of the lighting.  You can best see this as lower quality if you set it up as the first LOD and fly up to the tree.  You can see that the branches are all quads that rotate around some imaginary axes where the centers of the branches are.

The lowest level renders the whole tree as a quad that orients to the camera.  It has a texture altas of the tree from four different directions and it switches to them based on the view angle.  For hundreds and hundreds of trees, really far away, this looks pretty good.

Generally, I tend to have four levels of detail and I adjust the distances based on a compromise of quality and how many trees I would expect to have.

1) the highest level of detail is the full tree as I've defined it... all branches all the way down, etc..  I often set this to cut off pretty close to the tree.  Conservatively, about the point where when walking you'd be able to see enough under the canopy to see the missing branches in level 2.
2) still a full mesh, but limit the branch level to 1 or 2 (where the leaves will hide the branches) and the root level to 1 or so.  I may reduce the mesh quality (radials, etc.) as allowed by the cut off distance of (1).  The idea is the transition should look pretty smooth at whatever change distance was picked.
3) the 'flat poly' version where all branches are just quads.  This should reduce most trees down to 20 quads or so I guess... factoring in the depth limit in (2).  If you can get away with it, this distance cut off should be to the point where it's hard to see the 3D-ness of the leaf ball.
4) the imposter "sprites" as described above and this is the final level and goes out all the way until you want the trees to disappear.

I spend a lot of time playing with those parameters with a 10x10 forest with maximum position variation and a little rotation, leaning, and scaling variation.

In Dragonfly Odyssey I guess I was rendering thousands of trees this way... most of them flat imposters at any given time because of the distances.

It could also just be a problem with the launch4j exe wrapper.

You might try running something like SimArboreal directly (presuming you are using the .exe version normally... presuming there was an .exe version as my memory is fuzzy and I'm in a rush)...

Anyway, to run directly:
java -jar WhateverTheWrappedApp.exe

For Mythruna that won't really work on its own beyond the startup screen because you'll be running with default memory settings.  For my other stuff, it should work as a test at least.

My eyes stopped hating me today so I'll pick up the documentation again now. I'll talk about the updates on this post and add my ?'s to here as per usual.

Fixed the Mythruna references in the launcher settings documentation, added a print screen entry to the keybinds.

One thing I noticed about the print screen function is that without the skybox enabled, the sky is rendered as an alpha channel. It's a nice touch... even if it does that by default due to the black sky not actually being there.

I noticed in the "Tree" tab, a number of settings have a "(m)" Is that just a designation for meters?

The parameter "Texture U Repeat"... what does the U stand for?


I didn't make as much progress tonight as I'd hoped, but progress is progress.

Yes, (m) is for meters.

Texture U repeat controls how many times the texture will repeat on the U coordinate.  (As in "U,V texture coordinates".)

Ick.

Because of work I very rarely run anything about Java 7.  Kind of sucks that there are issues...

I'm posting this extremely early into the documentation because I'm slightly more clueless about this than I was about Mythruna, to put things lightly. That, and to document additions and such. Given that this documentation may need to be tranferred to a more official resource than a forum post, if you have any nitpicks at all, I can make adjustments accordingly.

For the launcher settings, I took a page from the Mythruna handbook since they're identical save for some naming conventions. It's a little less than concise, so if it needs to be scaled back, give me the word.

Seems fine... minus the few cases it mentions Mythruna directly.  The real target audience for the tool will kind of already know these settings but I understand that you are trying to cast a wider net.

So, first round of questions...

What can you tell me about the files in the github release? What significance do the folders and files outside of the release folder have, if any? Would a user have any reason to interact with files outside of the release folder?

If the "user" is a developer then they might.  The stuff outside of the release folder is the code for the tool.  For example, a developer can check it out and build it themselves, fix bugs they find, or just tweak it to their own needs.  Whatever.  Open Source for the win.

Are there any keybinds that I missed?

I can't think of any.  Ptrt-screen will save a PNG I think.

I assumed that the image sets from the tree atlas are from the cardinal directions. Is that accurate?

I think so.  It renders four of them.  They are either from the 45 degrees off cardinal, or plain cardinal.  Since they line up with the hi-res LOD then you should be able to orbit around the tree and see if they switch on the axis or at 45 degrees.  (If they switch on the axis then I took pictures from 45 degree angles.  If they switch on the 45 then I took cardinal... pretty sure it's that, though.)

Is the test pattern used to analyze how the texture is deformed by the tree? If not, how is it used?

Yes, that's right.  You can see how the texture is actually mapped around the mesh.  Useful for me when developing.  Useful for anyone else who wants to enhance the mesh extrusion code.  Useful for developers who might want to know exactly how the mesh is constructed for other reasons of their own.

It's a tool that was designed primarily for software developers... so it provides some things that might be useful there.

If there are any Mythruna fans that will be in the Northern VA area on July 30th... PM me.  I throw a big party every year for friends, family, co-workers, etc..

I guess I'll be picking your brain soon, then.

I'll try my best to document what I can based on intuition, first, of course. I have a good sense of about 1/4 or 1/3 of the options.

Oh, and uh... The j3o format is a touch restrictive, in that it can't be exported to another format. Perhaps it would be more popular if it could also export in another format... Though I don't know if that's even possible given my admittedly narrow understanding JME outside of the fact that j3o is a format used in JME. I guess the leaves wouldn't work in other formats either.

I looked at exporting to other formats but the problem is that the leaves rely on a certain custom shader to do the billboarding and lighting properly.  I'd have to come up with a different scheme for the leaves to export in different formats.

Would creating balls of randomly rotated flat surfaces, akin to Mythruna's leaves, do it?


Here's a test I did of it. The method I used for rotation wasn't as random as I'd like, but it does make clear that to make the leaves work well, super visible cross-sections would need to be prevented

Yeah, so far there are no particularly good solutions and all of those not-good solutions require development time that I don't have at the moment.