Again, thanks everyone for the feedback. Really helpful information. Faith
has it that I'm not suposed to actually give this a try... Tried to install
Win7 on my HP machine, and it messed up my EFI boot manager. So nothing
would boot up. And I'm really bad at error searching Windows errors.

So I'm installing CentOS again, need some familiar ground before making
another attempt.

With that said, I still think I will make some sort of attempt at creating
some "game ready" "award winning" "AAA class" models :)


regards
stefan



On Wed, May 15, 2013 at 11:26 AM, Martin <furik...@gmail.com> wrote:

> One thing that is very different from rendering works, is that you need to
> be very clean with your data, naming convetion may be more
> important, history and alive operators are not welcome.
> Basic scripting skills helps a lot even if you're not a TD, and specially
> if your company doesn't have too many TDs or no TDs at all. My workflow and
> my team workflow improved a lot when I learned a few scripting tricks. My
> data is cleaner and my clients happier.
>
> So, if you can't script, I really recommend you to learn some basic
> things. Basic scripting is more useful than ICE here, if you have to choose
> one.
>
> About mipmap, Mipmap generation is automatic. The format depends on your
> project. DDS is almost the standard in a lot of projects I've been
> involved. Some using Nvidia plugins, some other propietary tools but DDS
> has been quite the standard lately. Last time I did a Nintendo platform
> project we were using NW4C TGA. A format that comes with the Nintendo Tools
> package.
>
> Modeling software also changes depending on the project because the
> programmers may write their tools based only on one software.
> In Japan, Maya and Softimage are the most used. You need to match your
> client's version too, here is where Autodesk old version policies screw you
> if you have a subscription, 3 previous versions are not enough !!
> But most of the time we use 3 years versions (right now we are using SI
> 2011 in my current project).
>
> I haven't seen a single project based on Blender, but it doesn't mean that
> you can't use it, you just have to convert it to your client's software
> when you deliver your work.
>
> And here is where you'll have to learn how to live with conversions. They
> aren't as simple as we would like to. Sometimes you'll have to try FBX,
> Collada, Crosswalk, OBJ, because depending on the case one can be better
> than the other. And after that, you'll have to clean that data, because
> converted data have a lot of garbage. Here is where your scripting skills
> will save you hours of work. Specially if you need to convert animations.
>
> In no-SI projects, I usually do 80% of my modeling work in SI, convert it
> to Maya or Max and finish it there.
>
> M.Yara
>
>
> On Wed, May 15, 2013 at 5:52 PM, Stefan Andersson <sander...@gmail.com>wrote:
>
>> Great response everyone! Except for polycounts and fascist UV mapping, it
>> more or less sounds similar in a lot of ways to what I'm already doing. I
>> wont go into games trying to become a programmer, I do want to make art.
>> But as Matt suggested, I'm more likely to go art/tech since I'm somewhat of
>> a geek also.
>>
>> Mip mapping is something that I'm familiar with, and my own asset tools
>> already have it in place that I convert with OIIO all textures to be
>> mip-mapped and also the power of two (just because I don't trust anyone I
>> also resize them). But doing mip-mapping for a game engine, does that
>> requires to export each level? Or what image formats are usually used for
>> doing mip-mapping? I can't see game engines using exr... or do they? :)
>>
>> Before I go on and make Matt's little exercise I think I will build
>> something rigid and see how that looks. And I have to convert my
>> workstation from Linux to Windows.
>>
>> I talked to my brother who is working at Massive, and he thinks I'm an
>> idiot... but he also said that they base the size of the texture depending
>> on meters in the engine. I guess it also depends a lot of which engine you
>> will use.
>> But it leads me to another question. I'm not 100% sure yet which modeling
>> software I will be using. My 14+ years with both Maya / Softimage leaves me
>> somewhat in the middle of those two. Blender is also a contender, but I'll
>> stick with the programs that I know from inside and out. However, Softimage
>> doesn't have any metric units. Would the usual assumtion that 1 SI unit is
>> 10 cm still apply? or again... depends on the engine/exporter?
>>
>> all the best!
>>
>> your humble servant
>> stefan
>>
>>
>>
>>
>>
>> On Wed, May 15, 2013 at 10:26 AM, Matt Lind <ml...@carbinestudios.com>wrote:
>>
>>> Well, you can look at it from two different points of view:
>>>
>>> a) Do what many game artists do and brute force their way through making
>>> content with heavy iteration.
>>>
>>> b) Do what many game programmers do and try to be efficient.
>>>
>>>
>>> If you just want a job in games, follow path A which doesn't really
>>> require much learning on your part, but does require a lot of practice.
>>>  You need to follow the specs for whatever engine you're developing content
>>> for, and be frugal with whatever resources you have available to make the
>>> content.  The specs are project specific and change frequently.  Therefore,
>>> pick an engine and make something to function within it.  then choose a
>>> different engine and try to make the content function in that one too.
>>>  You'll quickly learn making functional content can be very difficult and
>>> is a skillset of itself.
>>>
>>> Following course B, anything a game programmer is going to tell you in
>>> making art is how to make the end result efficient for his needs.  he
>>> doesn't give a crap how many hours you spend on it or what it looks like.
>>>  He just wants it packaged in a tiny efficient form that doesn't blow up
>>> during runtime or induces expensive resources.  Since programmers are not
>>> artists, they don't know you want screenspace ambient occlusion, or fancy
>>> pixel based shading effects, or whatever.  In fact, they prefer you not use
>>> them because they want the CPU/GPU time for themselves to improve gameplay
>>> and other engine specific functions.
>>>
>>> So, if you want to make good art, retain sanity, and do a good job, your
>>> best bet is to starting learning computer science / computer architecture
>>> and apply the knowledge towards your artwork.  That is how the more
>>> successful game artists rise through the ranks as they are the ones that
>>> approach the programmers and suggest how art can be made better and more
>>> efficiently by applying technical knowledge to their art techniques.  If
>>> you rely on the programmer to figure it all out, you're going to be in for
>>> a lot of pain and feel unfulfilled by working in a very confined box.  If
>>> you rely on other artists to figure it out, you'll be in for even more pain
>>> as the chaos from lack of technical knowledge resulting in brute force
>>> techniques will drive you crazy.
>>>
>>>
>>> first assignment:
>>>
>>> Start with modeling.  The goal is to make the most robust looking
>>> bipedal character mesh that can be animated (deformed like an envelope)
>>> while being extremely frugal with polygon count.  Say, and entire seamless
>>> mesh at less than 5,000 polygons - triangles and quads only.  Keep
>>> iterating on it until you cannot find anything to iterate on anymore.
>>>  then, pretend a programmer enters your space and gives you a tongue
>>> lashing for exceeding the polygon count.  So redo the asset with a new
>>> polygon limit of 1,000 polygons.  sounds harsh, but as you do it, you'll
>>> discover things on the 1,000 polygon version that could be applied to the
>>> 5,000 polygon version you wouldn't have thought of until you were forced
>>> into the situation.  Basically its an excercise in determining artistic
>>> priorities.  once you reach the 1,000 polygon version satisfactorily,
>>> change the criteria to 400 polygons.  Once you finish the 400 polygon
>>> version, take what you learned and apply it back to the 5,000 polyg!
>>>  on version.  Actual polygon counts used in production vary with the
>>> platform and title.  Example: a boxing game on a console will probably
>>> throw 50K polygons or more at the characters because the environment is
>>> small and few subjects of interest.  An MMORPG running on a PC will devote
>>> under 10K per character because the worlds are large and there are many
>>> characters sharing the computing resources.  An embedded game running on a
>>> phone or tablet will probably use significantly less as the computing power
>>> is also much less.
>>>
>>> Once you finish modeling, apply an envelope with nulls as deformers, but
>>> limit yourself to 30 nulls for the entire character.  now make him bend and
>>> deform as expected with those 30 nulls and limit each vertex to being
>>> assigned to 4 bones/nulls or less - and that's a hard limit.  Now do that
>>> to the 5000 polygon, 1000 polygon and 400 polygon versions of the character
>>> so each looks as similar as possible to the others - including fingers and
>>> toes.  Notice how each behaves and must be constructed differently to reach
>>> the same end result.  Now you'll discover how you must retopologize your
>>> geometry - so take what you learned and start over again with the modeling.
>>>
>>> As for rendering....assume each texture applied consumes a render batch.
>>>  Think of batches as render passes performed on the GPU.  Each batch has a
>>> certain amount of setup cost which is often more expensive than the time
>>> spent rendering the contents of the batch.  Therefore it's critically
>>> important to minimize the number of batches you induce on the GPU.  Assume
>>> each light, shadow, and unique material induces a batch.  The name of the
>>> game is to create that character fully textured and lit using only 4
>>> batches with full normal mapping, cast shadows, and realtime lighting.
>>>  Texture images must be square with dimensions measuring a power of 2 (64,
>>> 128, 256, 512, 1024, etc...).  You can use one image map, and one normal
>>> map.  Again, specifics vary with platform and title.  The emphasis here is
>>> to teach you how to prioritize and be efficient.
>>>
>>>
>>> Matt
>>>
>>>
>>>
>>>
>>>
>>>
>>> ________________________________________
>>> From: softimage-boun...@listproc.autodesk.com [
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Andersson [
>>> sander...@gmail.com]
>>> Sent: Tuesday, May 14, 2013 11:46 PM
>>> To: softimage@listproc.autodesk.com
>>> Subject: Re: Texture size in games?
>>>
>>> Also, if and old dog like me that knows everything and nothing, where
>>> would be the best starting point? Conversion of "knowledge".
>>>
>>> Or rather "don't learn this, totally useless" :)
>>>
>>> Regards
>>> Stefan
>>>
>>>
>>> -- Sent from a phone booth in purgatory
>>>
>>> On May 15, 2013, at 8:31, Stefan Andersson <sander...@gmail.com> wrote:
>>>
>>> > Hi all!
>>> > This might be a strange question, but what would be the normal texture
>>> > size today when creating content for games?
>>> > I'm trying to learn a new profession and need to test out the basics
>>> > at home before I jump out into the void :)
>>> >
>>> > Also, would unity be a good practice platform? Or any other
>>> recommendations?
>>> >
>>> > I'm trying out something new here, so any suggestions and tips are
>>> welcomed!
>>> >
>>> > Best regards
>>> > Stefan
>>> >
>>> >
>>> > -- Sent from a phone booth in purgatory
>>>
>>
>>
>>
>> --
>> *Stefan Andersson | Digital Janitor **| Generalist for hire
>> *
>> blog <http://sanders3d.wordpress.com> | 
>> showreel<http://www.youtube.com/watch?v=qVb8yvxZcss>|
>> twitter <http://twitter.com/sanders3d> | 
>> LinkedIn<http://www.linkedin.com/in/sanders3d>|
>> Instagram <http://instagram.com/sanders3d_> | cell: +46-73-6268850 |
>> skype:sanders3d
>>
>>
>>
>


-- 
*Stefan Andersson | Digital Janitor **| Generalist for hire
*
blog <http://sanders3d.wordpress.com> |
showreel<http://www.youtube.com/watch?v=qVb8yvxZcss>|
twitter <http://twitter.com/sanders3d> |
LinkedIn<http://www.linkedin.com/in/sanders3d>|
Instagram <http://instagram.com/sanders3d_> | cell: +46-73-6268850 |
skype:sanders3d

Reply via email to