Page 4 of 6

Re: Korman 0.02 Released!

PostPosted: Sat Aug 01, 2015 11:49 am
by janaba
Sirius wrote:
Aloys wrote:I'm very tempted to unearth one of my old Ages to give it a try...
I certainly hope you have fun with it !
Tsar Hoikas wrote:Don't link here to D'ni, not yet!
Aloys, give Hoikas and his team the donuts, they deserve it. The donuts !... You have the donuts, right ?...
FOOL ! :lol:


Haha, yeah, they really do ... deserve it, eh them ... the donuts lol ... :lol:

Welcome back, Aloys, what a nice surprise ... :)

Re: Korman 0.02 Released!

PostPosted: Sat Aug 01, 2015 12:57 pm
by Aloys
Thanks. :)

Tweek wrote:Who the devil are you?

I don't know! :o But I come in peace, I swear. Eventhough I don't have donoughts.
(BTW, thanks for putting together your Intangibles site (just found about that yesterday). That will make following the project easier. :) )

Re: Korman 0.02 Released!

PostPosted: Mon Aug 03, 2015 1:59 pm
by Sirius
AhHHrrRRrghHHh !

I think I found out what was going wrong with the DrawableSpans being corrupted. It was... that my mesh was too big. Yup, it seems in some cases Korman will not notice that the mesh is too big, and just try to stuff as many vertices in a single vertex group, which ends up being too big to be read by Uru.
From what I guess, Korman checks the vertex count after Blender modifiers are applied. But then the vertex count increases when it is written to the DSpan, because Korman has to duplicate some vertices since Blender store some infos per-face and not per-vertex. For instance... UV mapping and vertex colors.
Meshes that are a tad too big (and close to the max vertex count) end up using a lot of duplicate vertices, because there are seams in the UV mapping, or because there are artifacts in the vertex color map.
And since I have the very bad habit of doing some very detailed terrain with lots of polygons for all my test Ages, I always run into this error. :evil:

Hmmm... Okay, now that I know that, I guess I'll split my terrain meshes a bit more often, sometime increase the efficiency of decimate modifiers, and it should go fine. Now, back to work...

Re: Korman 0.02 Released!

PostPosted: Mon Aug 03, 2015 2:21 pm
by Aloys
High poly meshes are always a bad idea. ;) If I remember correctly Plasma has an upper limit of 65536 vertices per mesh right? That's quite a lot of vertices, even for a terrain. What kind of huge/hyper detailed terrain do you use 65K+ vertices for? :o

Re: Korman 0.02 Released!

PostPosted: Mon Aug 03, 2015 4:46 pm
by Sirius
Ah, that would be my Canyon pet project, mentioned earlier in the topic ! The canyon itself is quite huge, and goes very far towards the horizon.
Because of the object's size, I made it very detailed to break its monotony.
The problem is I have a bad habit of not caring about optimizing meshes while I'm building - because it's annoying to do, and because I often have to tweak the mesh to fit other buildings, and therefore must keep the original mesh intact.
Long story short: the canyon was a single mesh with no details at first. Then I added detail using subsurf and a displacement map, but did not split the mesh when doing so. Meaning: the amount of detail was the same at closeup and at the horizon - which is very far, and thus is a complete waste of vertices.

To keep the number of polygons low, I only recently split the mesh into several parts, so I can use different settings for the Decimate modifier I'm using: closer parts now receive more vertices, while parts at the horizon receive almost nothing. This way, I use less vertices while keeping the same amount of detail.

Here is the canyon, split into multiple objects. The central (pink) part is the detailed one, and detail decreases as we approach the edges of the image.
Show Spoiler

The reason I was so reluctant to split it, was because in order to do so I must carefully re-fold the edges of each mesh so no seam can be found between two different meshes (the way I'm building it, seams are easy to spot). And that's pretty damn long to do.


Anyway, back to topic.

I finally had a peek at the logic node system, to wire a Python file to some simple logic... Awesome ! It's simple, intuitive, and it's impossible to link two incompatible nodes together.
The logic system I used worked at the first export without any need to manually edit the PRP. That's just great.

I'm having some trouble setting up dynamicenvmaps for wavesets, though... I simply setup an envmap for the material, which is exported, but attempting to read it in PrpShop crashes the program. Obviously Uru doesn't like it either, and simply ignores it, resulting in white wavesets.
For now I manually added an envmap to the PRP, but if you have pointers on how to set it up correctly...

Re: Korman 0.02 Released!

PostPosted: Tue Aug 04, 2015 4:38 am
by Aloys
Ah, right, I saw your earlier screenshot of that scene, looks nifty! :) I love the mix of high tech dome shaped buildings and a very wild landscape. Reminds me of some scenes in Star Wars.
The good old topic of terrain polycount optimization.. One could write an entire book about it. If you look at Cyan's terrain meshes you'll see that they are actually pretty light. The closest to your specific Age would be Ercana, and the whole Ercana_Canyon PRP has ~75,000 verticies (as imported by PyPRP years ago), and that including lots of stuff that isn't terrain (the big harvester vehicles, the train tracks, plants etc). Screenshot.
The common misconception is that one need to have a lot of triangles for a terrain to look good. But that's not true, especially in a real time games. Most of the detail should be carried by textures. (in most games normal maps would be used too, not so much in Uru; maybe baked in the lightmap? can we do that?). You *might* need lots of triangles if you are doing a very detailed thing like a mountain range; but for a cliff not so much. The key is to have more polys where it matters: ie not in flat areas. In curved areas, and on the 'silhouette' areas (at the top, near the water etc). Most parts of a cliff are usually pretty flat; you don't need too many polygons for that. Also, will the player be able to explore the top plateaus of your canyon? If not get rid of those too.
Also, starting with a dense mesh (like a grid) and subsurf-ying it can only lead to a super heavy mesh, but I guess you had already noticed that. ;) For a terrain (or any real time mesh for that matter) you want to do the opposite. Start with a simple mesh (most of my terrain work start with a cube or a circle), and then subdivide and move your vertices around as you need them. I agree it's a lot of manual work, but that's the best way to do it. In fact, I wouldn't be surprised if you have already spent as much time correcting your high poly mesh as you would have making a low poly mesh from scratch. :)

Anyyyhow, moving on, this is the Scripting forum. :) (I'll be happy to carry on this conversation somewhere else though).

Re: Korman 0.02 Released!

PostPosted: Wed Aug 05, 2015 2:24 pm
by Deledrius
Sirius, you might want to check out Blender's Dynamic Topology system. It's a quick way to get extra polygons only where you have additional detail, and you can still retopo later before export.

You could even bake the high-res mesh's AO and normal map onto the low-poly mesh, but I'm not sure how well that would work with Plasma...

Re: Korman 0.02 Released!

PostPosted: Fri Aug 28, 2015 1:49 pm
by cskid13
Are kickables supported yet in Korman?

Re: Korman 0.02 Released!

PostPosted: Sat Oct 17, 2015 9:40 am
by Sirius
Hey guys,

Just another stacktrace report, if it can help you improve Korman. This one is about animations. I've yet to understand what does that, it occurred all of a sudden on an animated object which exported fine until then. Deleting this object before exporting solves the issue.

The animated object has some logic attached to it - a simple clickable which fires a responder triggering an animation - all on the same object (except for the clickregion, of course).

It seems it stopped working when I added layer animations to another (completely unrelated) object, and it persists after I delete the newly animated object; so I'm not sure whether it's the cause of the problem or not.


Code: Select all
Traceback (most recent call last):
  File "C:\Games\Tools\Blender\Blender275a\2.75\scripts\addons\korman\operators\op_export.py", line 107, in execute
    e.run()
  File "C:\Games\Tools\Blender\Blender275a\2.75\scripts\addons\korman\exporter\convert.py", line 69, in run
    self._export_scene_objects()
  File "C:\Games\Tools\Blender\Blender275a\2.75\scripts\addons\korman\exporter\convert.py", line 203, in _export_scene_objects
    mod.export(self, bl_obj, sceneobject)
  File "C:\Games\Tools\Blender\Blender275a\2.75\scripts\addons\korman\properties\modifiers\anim.py", line 105, in export
    channel.controller = exporter.animation.convert_action2tm(action, matrix)
TypeError: controller should be a plController

Re: Korman 0.02 Released!

PostPosted: Sat Oct 17, 2015 9:43 am
by Tsar Hoikas
That indicates you have an action on the object, but there are no fcurves associated with said action.