ASE Export Script for Dark Radiant

[Fidcal]

Mmm... can't find the checkbox. Is this only for 1.5?

[greebo]

Are you sure you're using the correct script?

 

There should be a line like this in the .py file:

 

def processBrush(brushnode)

[Bikerdude]

thanks Greebs.

[Tels]

Ah, very good! That will come in handy!

[Bikerdude]

Mmm... can't find the checkbox. Is this only for 1.5?

 

Are you sure you're using the correct script? There should be a line like this in the .py file:

 

def processBrush(brushnode)

 

Greebs, there is no checkbox, but there is rather what looks like a selection box. I assume that's what you meant..?

[greebo]

Yeah, there is a mistake in the dialog interface, where checkboxes are rendered as togglebuttons. I already fixed that for the most recent SVN version, but the functionality is still there (the button can be toggled):

 

[Fidcal]

No button on mine but it shows v.0.3 so must be wrong path or something... mmm... I put it in scripts but I see a duplicate in scripts/commands so I'll move it there. ... Yes, working now, thanks.

[Tels]

A question about patches (and probably unrelated to the ASE export, but I don't know for sure):

 

Inspired by the scenic autumn outside, I was trying to create a small mushroom. That was much easier than I thought (create a cone, squash it, adjust subdivision, deform it, then clone it, invert the matrix, add a cylinder for the stem, deform it, add another cone for the bottom, done).

 

However, even in DR there are some triangles that look odd at the top,

 

 

and in game they appear black: (texture is a placeholder, I have photos of a real mushroom for reference):

 

 

How do I fix this?

[Fidcal]

Try increasing tesellation on patch inspector. That might fix it.

[Baddcog]

tesselation might fix the shading, but not likely.

 

the issue is that a cone is just a cylinder pinched at the top basically. So the texture at the top will always show non-tiling texture. it's also trying to smooth the lighting around it, not over the top. so it'll never look right. that's why i added a few more polys to my carrot so it didn't come to a one vert point at the end, was causing weird shading.

 

instead try this:

 

create cylinder, cap both ends.

grab both caps and make them twice as big round as the cylinder. move the bottom one up to top of cylinder. move the top one up a few units, hit V, pull the middle verts up. top cap is now rounded and will planar map and smooth correctly. place a gills texture on bottom cap.

 

^

_

||

 

there's your mushroom.

 

 

[Tels]

tesselation might fix the shading, but not likely.

 

the issue is that a cone is just a cylinder pinched at the top basically. So the texture at the top will always show non-tiling texture. it's also trying to smooth the lighting around it, not over the top. so it'll never look right. that's why i added a few more polys to my carrot so it didn't come to a one vert point at the end, was causing weird shading.

 

instead try this:

 

create cylinder, cap both ends.

grab both caps and make them twice as big round as the cylinder. move the bottom one up to top of cylinder. move the top one up a few units, hit V, pull the middle verts up. top cap is now rounded and will planar map and smooth correctly. place a gills texture on bottom cap.

 

^

_

||

 

there's your mushroom.

 

Hm,ok, if I understand you correctly, a "cylinder cap" is different from a "cone" and would fix the issue? If so, why would it do that, isn't a "cylinder cap" not simply a cone-squished-flat?

 

Gonne try it, anyway I don't care so much for the non-tiling etc, but the black triangles look like "Danger! Radiactive Mushroom! Do stand near!"

[Fidcal]

Sorry I looked at the wrong image. All you can do with the cone is scroll that black cross up until it disappears into the centre. If it appears at the bottom then try a larger scale.

[Baddcog]

nope, an end cap is not a cone, though you could make a cone from one.

 

but the end cap planar maps from the top. So tex looks good. but also lighting because the smoothing is across the surface verts.

 

the tex and lighting on a cone wraps around itm so it pinches up top in the middle. the smoothing groups for lighting can't smooth across the middle point, so the lghting is fighting between verts up top, thus giving weird vert shading.

 

scrolling the tex won't fix the pinched texture or smoothing groups.

[Fidcal]

It won't fix it but it can scroll that black x out of sight so it's not so noticeable.

 

http://forums.thedarkmod.com/topic/11328-self-lit-damageable-mushrooms-discuss/page__view__findpost__p__225671

[Baddcog]

well, your shot is from editor, his is in game. Do you not have shading issues with lights in game Fidcal?

 

unless Tels mushroom tex has black on it I don't see how scrolling the tex would fix the issue, because the vert lighting will still be the same.

 

Either way, it would take 1 minute to make a mush like I said and it would look much better, texture, shading and shape. (the cone mushroom has a very distinct sharp point on top)

[Tels]

well, your shot is from editor, his is in game. Do you not have shading issues with lights in game Fidcal?

 

unless Tels mushroom tex has black on it I don't see how scrolling the tex would fix the issue, because the vert lighting will still be the same.

 

Either way, it would take 1 minute to make a mush like I said and it would look much better, texture, shading and shape. (the cone mushroom has a very distinct sharp point on top)

 

Well, I based my model on our already existing and working boletus model, and it uses a cone on the top (or at least it looks like that in the editor), leading me to believe this is an issue with the ASE exporter.

 

Anyway, I tried briefly your "flat top" version inside DR, but I didn't have an opportunity to test it in game, so I have no idea if it would indeed work.

 

In any event, if people just waited until I tested it, or tested it themselves, we could have saved the last 5 speculative off-topic posts

[Tels]

Allright, back on topic

 

It is definitely something with the ASE exporter:

 

 

Note the difference on the ASE models on the left, compared to the func_statics from the map on the right. The "boletus" on the left is for comparisation. Note that the cylinder cap version as ASE doesn't have the black faces, but it still looks way too dark in game, somehow.

 

My guess is the normals are not generated properly? Hopefully that can be fixed, creating such small models in DR with the patch tools is very easy.

 

(Tip of the day: You can disperse colums with the Matrix menu. Also "inverting" a matrix means you flip the patch sides upside down, without having to flip the geometry.

[Baddcog]

 

 

In any event, if people just waited until I tested it, or tested it themselves, we could have saved the last 5 speculative off-topic posts

 

 

hmm, the vertex lighting across the top of the ase model doesn't light properly. Isn't that what I said twice? So I guess two of those posts can be unchecked from the speculative list.lol.

[Tels]

hmm, the vertex lighting across the top of the ase model doesn't light properly. Isn't that what I said twice? So I guess two of those posts can be unchecked from the speculative list.lol.

 

Er, yes, but if you look at the boletus, it works! Also, the func_statics work! So the problem is not with which type of patch I use, but how the func_static gets exported to ASE. Changing the func_static to some other patch works around the problem, but doesn't really fix it (as you can see,the ASE models are still way to dark compared to their func_static originals).

 

The ASE models should, however, but completely indentical to the func_statics. If the engine can render the func_statics that way, the ASE models should render exactly the same way, as they both contain the same data (same surface, same tris, same uv-coordinates).

 

Unless I am missing something fundamental here (Which, given that I know nothing about modeling might as well be

[Serpentine]

I think you're running into precision issues, while the native mesh data from the .map contains an arbitrary level of precision from whatever DR/etc saved it as, the ASE will have its input slopped. Due to the (technically they are correct, but it's a very messy way for doom to handle with them) way that the ASE export exports grouping and such it's most likely that the precision and inclusion of unnecessary cruft is leading to the parsed model having in-facing normals or broken UV-coords. You can try decreasing the slop decimal for all 3 values, it's a shot. Otherwise I'm sure that a single GEOM group in the ASE with a single smoothing group and welded vertices would work... but that's a little bit more work than it's really worth

 

But as per usual, this carries the "Serp is most likely making up shit" disclaimer.

[rich_is_bored]

All the export script does is say "Hey, can you supply me with vertex, face, and material data for this brush or patch?"

 

This is true for vertex normals as well. It's possible to ignore the information Dark Radiant provides and calculate them from scratch but ideally DR should provide the correct information in the first place.

 

That said, considering the way a texture wraps around a cone, that's a horrible way to construct a mushroom.

[Tels]

This is true for vertex normals as well. It's possible to ignore the information Dark Radiant provides and calculate them from scratch but ideally DR should provide the correct information in the first place.

 

So should I file a bugreport for DR? Also, this makes me wonder, why are the face-normals wrong for the ASE, but show better (correctly?) inside DR?

 

That said, considering the way a texture wraps around a cone, that's a horrible way to construct a mushroom.

 

So, why does it work for the boletus? What's different for it?

 

Also, if I use an cylinder endcap, I still run into the normals issue. Is this the same bug for DR? And is there a chance that the script corrects this on export as a workaround (that might be faster to accomplish than correcting DR)?

 

Last but not least: Thank you for your work! I love the exporter. Hopefully this can be fixed, so I am no longer limited to flat faces

 

Edit: Pretend I know nothing about models, so please answer like you would answer someone who has no clue

[rich_is_bored]

I haven't confirmed the issue is with DR. I'm just expressing my suspicions based on what I know about how the exporter works. Until I'm certain I won't file a bug report and I don't recommend you do so on my behalf.

 

As for the technique of using a patch cone or cylinder for a mushroom cap, the boletus model you point out is not uv mapped the same way. The cap is planar mapped while a patch cone or cylinder would wrap around.

 

Here's a top down view of the boletus model with a checkerboard texture...

 

 

Now here's a top down view of a patch cone...

 

 

Notice how on the boletus model the texture does not get pinched in the center? That's because of how the model is UV mapped. The texture is applied to the cap of the mushroom as if was being projected on to it from the top.

 

In the case of a patch cone or cylinder, the texture wraps around it. That's not good because the texture gets pinched at the pole. Perhaps there's a way to adjust the UVs within DR using the texture tool or Shift+MMB but leaving the texture mapped as it is by default is no good.

 

In fact, now that I think about it, that pinching could be the reason why it looks dark in game. You're pinching the normal map too.

Edited October 8, 2010 by rich_is_bored

[Tels]

Confirming the "dark faces" issue with DR would be cool (because the func_static renders differently from the ASE and that shouldn't be the case, or?)

 

rich, thanx for the good explanation. I also noticed that while a cylinder cap is not pinched at the top, it gets pinched at the sides, so its no good, either.

 

As for the texture tool, yeah, I guess it would possible to adjust the uvmap, but it might get complicated to do this manually due to the "warping". I'll experiment with using a flat patch and then just moving the vertices around and maybe using a new material with a circular area and alphatest for the outside.

[rich_is_bored]

Okay, I've looked over a test model in game in comparison to the patch mesh cone that it was exported from and the normals are considerably different. Oddly enough even though the cone model tapers off to a point, the normals continue to point outward as if it were still a cylinder.

 

I've also reviewed the script and as I suspected, nothing is being done to the normals. They are fetched and exported as is.

 

But I'm noticing something strange about the normals produced by a patch that makes me believe the engine treats them as a special case. As you know a patch cone isn't really a cone at all. It's just a cylinder where the vertices at one end are collapsed into a single point in space.

 

But those vertices are not merged. They remain separate and yet the vertex normals at that location point straight up. You shouldn't get normals like this unless the vertices are merged. Let me try and draft up an illustration real quick...

 

 

You can see this yourself if you use r_shownormals in game.