Non-smooth lighting

[Aloys]

As I'm trying to improve my miserable skills in lighting something really ticks me off: lighting on objects in Uru is smooth regardless of whether my objects in Blender are smooth or solid..
The only way I've found to actually get faces on objects to be solid is to 'split' the faces I want to be solid (select face and then 'Y'), so that they don't share comnon vertices with the adjacent faces, and this way it won't be smoothed. Now this is fun and dandy and all but I have to do that on all faces one by one and this is just not possible to do that on objects where who have hundreds of faces... Is there some trick I'm missing out or is this just simply not supported (yet) by PyPRP? If this is indeed not supported, would anyone know of a trick to split all selected faces at once?

[Chacal]

?
Explain "smooth" as pertaining to lighting.

[Aloys]

Technically, it doesn't really have to do with the lighthing, but more with the objects and whether its faced are tagged as 'smooth' (in which case the lighting result is smoothed accross the adjacent faces) or 'solid'.
In Blender go to Edit Mode, select some faces of your object, hit 'W' and fiddle with 'Set Smooth' and 'Set Solid'.

[D'Lanor]

I had that solid kind of lighting in Uru when there were double vertices on my objects.

[D'eux]

I know what Aloys is getting at. Most 3D apps allow a smoothing threshold to be set so that you can render an objects as 'sharp' or 'smooth' depending on the angle of light hitting the face. The most common threshold is 30 degrees. Blender has the 'Auto Smooth' feature for this which has the threshold value below it. But as already said, I don't think PyPRP supports this (yet). A good example of using this would be if you wanted a disco mirror ball - i.e. a ball made up of flat facets that you didn't want to be smoothed out in Plasma.

-: D'eux :-

[Nadnerb]

I've run into this as well. The simple fact is that because plasma stores all normals in the vertexes, (while blender can store them per-face) the vertexes must be split in the output files in order to achieve solid lighting. Generally, I don't have that much of a problem with splitting faces though, but then, I've never tried to rip apart an entire sphere.

[Aloys]

Well, I haven't either, and I don't want to.
But you can need sharp lighting for many things other than disco balls. In fact for pretty much anything that doesn't explicitely require smooth lighting.. Anything with sharp angles: architecture, mechanims, pretty much anything, even rocks. But as it stands because of that problem even if I make a simple cube with right angles everywhere it still ends up looking perfectly smooth in Plasma.. And it is getting quite consuming to separate faces everytime (not to mention totally impractical for high polycounts objects..)

Lontahv mentionned to me that it is a good idea to make the object solid in Blender and bake the lighting directly in the Vertex paintin. And that is very usefull, but to me the big downside here is that afterwards you can't change the vertex painting at all, because as soon as you do Blender smooth ou all the exisiting vertex painting! (don't ask me why).. So that mean you either have to go with fully automatic vertex painting or fully manual.. And neither solution is fully satisfying..

[Grogyan]

Just to let everyone know that Blender 2.46 when it comes available will be able to make "soft light maps", unless you are talking about what is rendered in real time, then that is a limitation with game and has always been there including MOUL

[Trylon]

What aloys wants requires turning off PyPRP's vertex compacting code. There's no way t do that per-object (yet).

The vertex compacting code avoids making unnecessary doubles of verteces for adjacent faces. (PyPrp 0.5 made a copy of a vertex for each face that used it, resuling in relatively high vertex counts).

[Owehn]

What about "seams"? I think that at some point I remember putting seams on some edges of an object, for some reason to do with UV mapping. Are seams currently being used for anything else? If not, that might be a good way to tell PyPRP (in the future) which places you don't want vertex compacting.