TSR has already a Workshop for CC...

<< < (7/21) > >>

anonymouscoward:
Actually, objects can be colored in many ways other than UV maps, and "materials" (usually parameters related to the object's interaction with light) are not always synonymous with textures (they are two different things in, for example, Blender), and games traditionally do not rely on "materials" as much because they can be computationally intensive and are thus more common in 3D for stills or animations. There are also numerous other projection methods, planar, cylindrical, you name it. Shaders (which are synonymous with materials in some apps) can be used instead of images or materials or in combination with them. UV mapping just happens to be the most efficient for 3D gaming or at least the most commonly used because, I guess, it better utilizes the memory resources of the graphics card while using very little processing time. Assigning separate images to regions on a single object is right off the bat a less efficient way to do it assuming separate graphic assets were loaded for each region and might cause a hit in graphics performance. However, on the other hand "procedural" is currently the rage in optimizing game engine performance. Making something "procedural" is taking game elements or assets that were formerly hand made, such as animations, and calculating them at run time to move some of the burden from the graphics card to the CPU and cut costs and time for asset creation (this example obviously not being used extensively in TS3 where they seem to use the same animation assets from TS2 and most animation transitions still segue first to a "default" state before going on to the next move, the toddler being the most obvious where he/she walks to the potty, sits down, slides, gets back up, then sits on the potty...).

Despite all this, it is obvious from looking at CAS that separate "images" (whether actual bit map image files or some other device) are assigned to separate regions. That they can't be resized using a slider and the subsequent blurriness in game seems to rule out the possibility that vector graphics are being used, but that is not definite. Looking at the wood textures, for example, they appear to have a lower number of colors used, so it almost does seem as if they were using a vector graphic format which would be much easier to procedurally adjust to diverse geometry at run time, would take up much less memory, and would explain the ability to easily alter individual colors within a given texture pattern. It would explain the "cartoony" look of many game objects. The more I think of it, I would implement this using vector graphics and then rasterize them on the fly. For those who are lost on this, raster graphics means the normal ones you make in Photoshop etc. made from pixels, vector graphics are stuff like Flash or Illustrator that use line, curve, and area definitions to describe the image so no matter how much you zoom in you never see jagged edges.

So anyway, point being that I think more is going on under the hood than one might have expected. My gut feeling is that "recolors" isn't going to be as easy as the standard method of generating or reusing a UV template and dressing it up in Photoshop or whatever. I would not be surprised if vector graphic "patterns" were the only form of texturing accepted for many objects with the exception of, obviously, UV mapped bump/normal maps and also perhaps a UV mapped grey scale image for "baked" shadow details that may be what they are doing to mitigate some of the flat bland cartoonish quality. Those last two would obviously have to be generated at the object modeling stage because whereas normal maps have until now been usually fudged from the basic color image map, the TS3 patterns have no information in them which could generate normal maps. So for the really high end object creation you would have to model a detailed object, generate your normal map and baked shadows, then reduce polycount (and detail) for the object you actually import to the game, which is the standard method for next gen games at the moment.

This is all just to give everyone an idea of what the TSR people would have to be tackling to produce what they claim they are producing. If they succeed, you would be hard pressed to come up with a better tool, politics aside.

anonymouscoward:
Quote from: GelatinousSubstance on 2009 May 28, 16:39:20

It's really just a matter of knowing the naming scheme of the objects and knowing how to get them into the game.


But now I get what you are saying. Getting the objects into the game and getting the textures into the game are, unlike TS2, largely two entirely different processes for CAS or build colorable objects. You could import an untextured object as long as it had the regions defined/named properly, which is precisely what the TSR tool says it will do.....doh  :P Got it :) Still, that method would be missing the baked shadows and normal maps step which would have to be included or the imported objects would stick out like a sore thumb.

Edit: but (probable) baked shadow maps appear in the drop down menu in one of the screen shots. Interesting. Perhaps that means they are successfully reading the in game file format without conversion.

Tacuitacitum:
Quote from: anonymouscoward on 2009 May 29, 01:57:37

Lots of technical stuff


I was inclined to think that the clothes at least might be UV mapped because I'm getting 'bleed' of areas (such as belt colour 'bleeding' into the clothes, and pattern edges being blurry - on highest detail level), which is common if your texture map for your UVs is small. That said, I've never experimented much with vector texturing, and that does explain being able to change the colour without eating insane amounts of memory. It's possible the vectors are rasterised but still quite small, which would cause the blur. If vectors were used in Splotch I'd be inclined to think they'd use a similar system for Sims 3, although Splotch wasn't quite so blurry to me.

If it's materials, then it's going to be quite difficult to take out of game - usually materials are set by the software, rather than by an external file, unless Sims allows access to its material/shader files?

For a straightforward object then cubic, planar, spherical texture projections would would just dandy - I can forsee lots of beginner objects having horribly skewed textures if people have to make unique UV-projections, or attempt to map a complex object with a simple projection.

If we're able to use normal maps for detail as opposed to a rediculously high poly, then that's awesome as far as speed ingame is concerned, and it's (afaik) standard for games that want large amounts of detail but not at the expense of speed. At the same time, unless Blender allows you to create normal maps by projecting the high poly onto low poly, I'm not sure of any free 3D apps that have that feature. (And now that the major 3 3D apps have been bought by the same company, their prices are probable soon to rocket)

Are you suggesting that one creates a seperate map for baked shadows (say, ambient occlusion-like shadows as opposed to direct cast shadows, which would be impossible to know without a lightsource) which is then layered over the pattern texture? That's quite nifty - I haven't noticed it myself, but then I haven't been looking for it. I suppose that's exactly the point - subtlety. Is there any ambient occlusion between objects, btw?

How about Sims skins? They're horribly bland at the moment, but of course one can't make a set of individual skins - they've got to be slider-able, and would presumably need to be default replacements. Unless there's a very simple darken/lighten/levels/whathaveyou tool, I'm not sure what format you'd need to make the skin with.

rufio:
Coconut weighs in on this issue.

Inge:
Coconut does not have the full facts.  Based on the facts she probably does have, I can understand her point of view.

Navigation

[0] Message Index

[#] Next page

[*] Previous page