My models

[Bikerdude]

Sweet (I thinkg I vaglue remember asking you this before also..sorry)

 

And I think Ive asked this before, but whats are your views on the subject of .ASE models created in DR with a shadow etc.

[Springheel]

In general, I'm not a fan.

 

1. I have no way to work on .ase models and have to rely on others to make changes if something is amiss. This has been a problem more times that I like to remember.

2. Models made in DR are not going to have a normalmap made from a high-poly model, so they're never going to be as good as models that do.

 

That said, there are some instances where it might make sense, like building facades that would be using stock textures anyway. Ultimately, I care about the overall quality of the model (assuming it's being put forward as a potential core asset), not how it was made.

[Bikerdude]

Right,

1. In that case then, in terms of my workflow I will look for a way to convert the .ASE models I make into .LWO so you can do a once over on them etc.
   
2. you say that, but the texture i would use in DR have a normal..?
   

[Springheel]

you say that, but the texture i would use in DR have a normal..?

 

On flat surfaces that might be fine, but not so much on rounded surfaces. But as I said, it depends. I'm sure someone could get great results from DR in certain conditions on certain kinds of models.

[Tels]

In general, I'm not a fan.

 

1. I have no way to work on .ase models and have to rely on others to make changes if something is amiss. This has been a problem more times that I like to remember.

2. Models made in DR are not going to have a normalmap made from a high-poly model, so they're never going to be as good as models that do.

 

That said, there are some instances where it might make sense, like building facades that would be using stock textures anyway. Ultimately, I care about the overall quality of the model (assuming it's being put forward as a potential core asset), not how it was made.

 

In some cases, the DR models are "good enough", however. See some keys for instance. It really depends and I agree that the model quality should be the important thing, not how it was made.

[Springheel]

I'm not impressed with some of our key models. Often times models that are "good enough" at one stage of development start to fall behind as our standards improve.

Edited December 10, 2014 by Springheel

[nbohr1more]

One problem with DR ASE models is that they do not have normals\smoothing groups. Which, when paired with the fact that almost

no mapper makes their own full-model normal map bake, means that you need to use an outrageous number of polys to get a good curved look.

[Bikerdude]

One problem with DR ASE models is that they do not have normals\smoothing groups.

Ah yes, that would explain why Spings wine_bottles model had massively less verts than my ASE version.

[nbohr1more]

Yep, we could possibly alter the map format to add "vertex normals" to brushes but it was already deemed too risky to introduce "vertex color".

Maybe if someone did a prototype of that change there would be less FUD around it...

 

I guess you could make Springheel's job easier by supplying both a high-poly and lower-poly model so he can fix the smoothing on both in Lightwave

then bake the normals. (not that that's a chore he wants to do either...but if it's a nice enough asset it'll probably be worth it)

 

Edit: Does the ASE export preserve vertex normals when exporting patches?

[Bikerdude]

• I guess you could make Springheel's job easier by supplying both a high-poly and lower-poly model so he can fix the smoothing on both in Lightwave then bake the normals. (not that that's a chore he wants to do either...but if it's a nice enough asset it'll probably be worth it)
  
• Edit: Does the ASE export preserve vertex normals when exporting patches?
  

• When I make a model in DR I do with just enough divisions/tessellation so you don't see the hard edges on curved surfaces. and then also create a low poly version for the shadowmesh.
  
• no idea, I don't think the export script is that sophisticated.
  

[Obsttorte]

Yep, we could possibly alter the map format to add "vertex normals" to brushes but it was already deemed too risky to introduce "vertex color".

Maybe if someone did a prototype of that change there would be less FUD around it...

 

Edit: Does the ASE export preserve vertex normals when exporting patches?

Brushes have vertex normals, but they aren't stored seperately as they equals the face normal. (That's why brushes looks so blocky).

 

The ASE export script preserves the normals of the patches. If you are aiming for creating models in DR that looks round, you have to use patches, as the vertex normals are the intermediate value of the face normals of all touching faces. This doesn't count for brushes as said above, which makes them good if you want to have blocky/edgy looking things.

 

1. I have no way to work on .ase models and have to rely on others to make changes if something is amiss. This has been a problem more times that I like to remember.

2. Models made in DR are not going to have a normalmap made from a high-poly model, so they're never going to be as good as models that do.

As obj. is a text format, it should be possible to write a program converting from ase to obj. I thought about that a while ago already, as sculptris reads obj format for example, but almost no program reads ase. This would allow to create models in DR, and either use ASE export and conversion to obj or obj export (which would have to be written, too, god how I hate python) to make it accessible to modelling programs, which could be used to create the baked normal map and poly down the model.

 

A lwo export script would be neat, too, but I didn't find a documentation about it's definition and as it's binary I cannot decrypt it myself.

[Arcturus]

One problem with DR ASE models is that they do not have normals\smoothing groups. Which, when paired with the fact that almost

no mapper makes their own full-model normal map bake, means that you need to use an outrageous number of polys to get a good curved look.

ASE models are smothed by default. If you want a sharp edge you need to split edges. But there are no problems making round objects. I guess ase exporter in Darkradiant exports brushes with split edges?

[Tels]

ASE models are smothed by default. If you want a sharp edge you need to split edges. But there are no problems making round objects. I guess ase exporter in Darkradiant exports brushes with split edges?

 

Good question.

 

On related terms, making things to appear more round is possible, f.i. we have materials for iron bars where you have a square bar and it appears round in game. It's only obvious at the ends of the bars.

 

This technique is probably not often used, instead patches with more faces are used.

[Atheran]

I still believe adding support for obj in DR is easier than writting mini programs to convert file types but to each their own I guess.

 

As for the engine I started building the low-poly mesh and doing retopology at the same time. In that way I'll end up with pretty good UVs hopefully. After that I'll try to bake the normal maps from high-poly to low-poly (not my cup of tea, baking the normal maps, that is). If I manage to get some good looking normals then perfect, otherwise I'll have to up the polycount a bit on the low poly for some needed details but we'll get a sqare(ish) model. Then it's texturing time but all this will take me until next week probably as my time is limited.

 

For the texturing part, does DR use AO maps, or there's no need to bake stuff like AO/lum/etc etc? I know for fact I don't need to bake a height map because tesselation is not a thing yet but what others do I need besides diffuse/normal/spec?

[Springheel]

For the texturing part, does DR use AO maps

 

It can, yes.

[Obsttorte]

ASE models are smothed by default. If you want a sharp edge you need to split edges. But there are no problems making round objects. I guess ase exporter in Darkradiant exports brushes with split edges?

Each tris is exported on its own and has its own face and vertex normals. So one vertex will appear several times for brushes, once for every adjacenting face, and each time with a vertex normal that equals the face normal.

 

I hope this is a sufficient answer as I'm not sure I understood the question

[Obsttorte]

What are AO maps?

[Springheel]

Ambient Occlusion. We don't use them very often, but it's something that can be supported in material shaders (and is a great way to use generic textures on prop meshes and still look good).

[Atheran]

AO maps usually give a nice feel of depth and/or soft shadows. In the renders of the generator I simply used a lambert material with soft AO and one point light in case it helps you understand what they look like

[Obsttorte]

Ambient Occlusion. We don't use them very often, but it's something that can be supported in material shaders (and is a great way to use generic textures on prop meshes and still look good).

Is there a wiki entry about this, or something else I can read this up?

[Springheel]

Is there a wiki entry about this, or something else I can read this up?

 

In general, or how to do it in TDM?

[Bikerdude]

On a related note, is there any reason why we could not have an .OBJ or even .LWO exporter script for DR...? Removing the need for a 3rd party app, and allowing Springs toi directly work on any DR models people make.

[Arcturus]

Each tris is exported on its own and has its own face and vertex normals. So one vertex will appear several times for brushes, once for every adjacenting face, and each time with a vertex normal that equals the face normal.

Yes, that is what I mean by 'split edges'.

This is ASE from Blender. No smooth groups or normalmaps are required for the smooth shading:

 

[Arcturus]

On a related note, is there any reason why we could not have an .OBJ or even .LWO exporter script for DR...?

.obj exporter has always been there.

[Bikerdude]

.obj exporter has always been there.

Well it aint in the latest version 2.0.2 so it must have been removed at some point.