Page 2 of 2

Re: UV texture coordinates

Posted: Thu Jan 13, 2011 12:56 pm
by AdamB
booman wrote:Ok, you are saying LighUp is exporting the scale correctly but UDK is converting the scale incorrectly.
This is strange because the ASE export works fine and imports fine.
LightUp performs no scaling on export. However, FBX files contain the Units the model is defined in, so I think what is happening is that the UDK FBX reader is assuming/parsing the model is in inches and converting inches to centimetres - hence the scaling by 2.54.

Its been a few years since I've played with ASE files, but my memory is that they have no info specifying the units of the model (inch/cm etc).
The ASE files you're using must therefore be assumed to be in centimetres already - hence no scaling is applied. This is consistent with your experiment you describe in this thread: http://www.light-up.co.uk/forum/viewtop ... =759#p3107

Basically UDK appears to like working in centimetres, so FWIW, I'd suggest you work in centimetres in SketchUp too.

Re: UV texture coordinates

Posted: Thu Jan 13, 2011 1:07 pm
by booman
That is exactly what I thought of too. Change the scale to Centimeters.
I'll give it a try and do some more experiments, Thanks Adam

Re: UV texture coordinates

Posted: Thu Jan 20, 2011 12:34 pm
by jaceguay
AdamB wrote:Interesting.

So there are a couple of ways you can approach this and I'm not clear which you're proposing.

1. During the export process, perform an optimization of the materials by finding non-tiled materials and create a single texture atlas for them all - thus merging many materials into a single material. This reduces drawcalls and increases runtime performance. We can also apply my Goldilocks plugin to texture dimensions to ensure you have just enough texture resolution based on any Scenes you have setup.

2. Create a texture with the same layout as lightmapping which contains the albedo info. The problem with this is that lighting is often a low frequency function at a lower resolution that you'll normally have for your base textures. Retaining the crispness of the base texture (which may be tiled) is going to require a texture with much higher resolution (albeit with the same unwrap layout). In some ways, doing this runs completely against the advantages of splitting out light effects from the base textures.

Adam
I vote for the second approach, I could use in Valve´s Hammer even at low resolution, to built some prefabs.

Re: UV texture coordinates

Posted: Thu Jan 20, 2011 1:17 pm
by AdamB
On a vaguely related note, did you know LightUp can read Valve VTF format skyboxes and textures.

Adam

Re: UV texture coordinates

Posted: Thu Jan 20, 2011 1:38 pm
by booman
No I didn't, so does that mean I can import or export as VTF?
I may be able to use that format in Blender as long as it retains UV Coordinates.

I finally figured out that the OBJ format retains UV coordinates from Sketchup to Blender. Now I can create my lightmaps and UV channels with Blender, but that means I'll have to skip LightUp in the process.
I did try to import the Lmap image from LightUp into Blender but it doesn't have the same coordinates as the Blender Lightmap unwrap coordinates.
So that didn't help me yet.

I'll look up the VTF format and see what it can do.
Thanks Adam

Re: UV texture coordinates

Posted: Mon Jan 31, 2011 7:08 pm
by booman
Not sure how many of you are UDK developers but I have mixed results with Sketchup, Lightup and UDK.
If you have read my earlier posts you will see that I am having lighting issues with vertex lighting vs pixel lighting in UDK. This really affects how your model looks in-game. Most of my models are exported from Sketchup as .ASE and can be directly imported into UDK, but lighting and shadows are distorted and look bad.
So I have been researching and doing tests for the last month and still do not have a successful result. Here are my findings:

ASE static mesh models require some sort of lightmap assigned to a 2nd UV channel in the file
Static meshes with lightmaps are usually 1000 polygons or more
Apparently less that 1000 polygons do not require a lightmap, but my models have bad artifacts and distorted shadows on the model
Blender can create lightmaps and assign the 2nd UV channel - but I still have the same artifacts
Static Mesh models may require vertex smoothing - Sketchup cannot do this
LightUp creates lightmaps in Sketchup and exports as FBX - success import into UDK and no artifacts, but no texture coordinates.

So ironicly LightUp actually creates the exact model from Sketchup with lightmapping and looks amazing, but just a white color.
I have tried UV mapping in Blender by unwrapping my models and exporting the coordinates along with the lightmaps, but have not had any success. There are about 50 steps in that process.
Man, if LightUp could somehow exports the textures coordinates just like the lightmap or at least combine them, that would make my day. I could crank out a few static meshes a day because SketchUp is so easy to use.

Thanks for your time

Re: UV texture coordinates

Posted: Sat Apr 23, 2016 4:53 pm
by prader@nvizeon.com
I've been following this same logic and trying to get a fully lit model into Unreal with no success. In the end, it's a problem with the 2nd channel UV. Bringing a model into Blender and making a UV map for All objects would be super time consuming.

There is a plugin for Sketchup called BlendUP which does a nice job of exporting a fully textured model into Blender even converting meshes to quads in the process.

http://sketchup2blender.com/

Works great. But Alas no lighting.

It would be wonderful if LightUP could export directly to Blender or Unreal with texture coordinates, texture maps, uvmaps and 2nd channel UV lightmaps.

IE: game ready models Imported directly into the game engine.

Re: UV texture coordinates

Posted: Mon Apr 25, 2016 5:31 pm
by booman
Wow, this is an old thread.
Thanks for the link and the information.
SketchUp has been an amazing tool, even for game design. But like you said, its not always optimized for in-game lighting and dynamic shadows, etc.