What's Poser have to do with game making ?

Poser has always been able to be used to render sprites for use in 2D game development.  I did a bit of that, as far back as 2002.

The upcoming Game Dev version of Poser Pro 2014 that has been announced will offer several useful tools for figure import and export, with FBX as well as COLLADA available as an export format.  I think there was mention of the Game Dev version being developed especially to work well with game development platforms like Unity.  This could be very useful for 3D game developers, to be able to create and animate a figure using Poser's tools, then export directly to a format the game engine can use.  I've tried a bunch of things over the years to integrate Poser into a 3D game development workflow, and previously it hasn't been easy.  :lol:  Poser's Game Dev version should make such things much more approachable.  One of these days I'll have to get around to trying that free version of Unity.  :unsure:

http://poser.smithmicro.com/gamedev.html

Quote - http://poser.smithmicro.com/gamedev.html

The wireframe .jpg with a tri mesh that's been subDed.

it's not a correct topology SubD mesh.
it's not a correct topology game mesh.

What is that suspose to be for ?

I kind of wonder if that mesh is meant to illustrate the Polygon Reduction system...?  :unsure:  I thought it was a strange mesh to use while advertising optimization for gaming.  Not quite sure what we're supposed to be seeing, when we look at the pomotional artwork.  Hmm.

PP2014 Game Dev is gonna be a good version for Game builders.

Combining figures into one.
Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Optional, you can use the polygon reduction tool to reduce the number of polygons.

This is also very useful for current Poser users to build easy manipulatable background figures, to reduce system load in populated scenes.

Then you "can" export to FBX or Colada, bake morphs and bake a new texture, to let Poser build game compatible "full" figures.

Figure+hair+clothing+shoes, all become one. 
Reduced in Polygons if required, baked morphs if required, and with a new texture if required.

These are some nice features for Game builders to prepare their figures using Poser content and the vast availability of hair and clothing support files available.

http://poser.smithmicro.com/gamedev.html

How is licencing for distributing the combined and reduced meshes going to work? Will there be a different EULA for users of the game dev version?

According to the page at Smith Micro,

Quote - "Poser Pro Game Dev includes a 5GB library of 3D characters, clothing, props and scene elements that you can export for delivery in your game."

This tells me that the 5GB of included content doesn't require a special license for game dev (good selling point), but you will need a separate game dev license from each vendor whose content you intend on using in your game, because only that vendor can decide whether their content is allowed to be used in games. 

For 2D games that only use sprites (2D animated images) the standard EULA should apply to most purchased content, since geometry and other assets can't be extracted from an image, and most commercial content allows the use in commercial products (animations, web comics, etc). In that case you would only be bound by the usage limits that come with whatever content you're using (ie: most free poser content generally doesn't allow for commercial use in 2D or 3D). 

At least, this is how I'm understanding it. 

Combining figures into one.
Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Most call that boolean.would be nice if all the cgi app's called everthing the same thing.

boolean cloths hair shoes etc etc and have a easy ready made game mesh fast sounds good.
but to have a clean mesh and maps with out having to clean it up in Max will be a trick.

http://poser.smithmicro.com/pproGameDev_specsheet_final_FULLRES.pdf

Do games even use dynamic hair,cloths ,Bullet Physics,weight map rigs ?

game developers see the .jpgs and read some of this stuff.
wounder what there think.

for 3D games

would game makers buy ready to use out of the box game meshes from Poser ,
If there good sure.
animate them in Poser ,maybe.
all the reast I have my doubts.
I just don't get the felling that Poser has anyone working for them that actually makes and understands game making.

the ones using blender for games probably be interested but there not the spenders.
Unless Poser really delivers clean booleaned meshes with out any clean up.
Just don't see a lot of Maxers suport.

Quote - What's Poser have to do with game making ?

The original purpose of Poser was to replace the wooden artists' mannequin.  In time more features were added, and people began to use Poser for illustration and animation as well. 

This is just the natural evolution of Poser.  Many Poser artists are involved in aspects of creation, whether modding existing games, creating indie games, or even working on huge blockbusters professionally.

Poser has many of the same tools that are used in creating animated characters for games, but is also lacking in key features specific to doing this.  Adding those features to Poser not only makes the program useful to a wider audience, but also provides useful features to current users who may not yet be aware of when or why those features woud be useful.

Optimizing figures for use in games should also give the benefit of allowing us to have more figures in our current scenes, for example.  Or in the case of fewer figures we should also see faster rendering due to consolidation of materials/textures and removal of unseen geometry.

     I'll second Moogal, and elaborate a bit myself.

    RorrKonn, I don't play or make video games, but can you not see potential here, for "traditional" Poser use?

     Consider a scene where you want to populate Tink's Cafe'.  Imagine the RAM -and CPU cycles- you'll save by removing the underlying unseen polys of the filler dolls, combining doll/hair/shirt/pants/shoes into a single figure, and maybe decimating (reducing poly count) of the figure?  Wouldn't that be a boon to getting a heavy Poser scene rendered?  Imagine how much more manageable your hierarchy menu will be for twelve (fully dressed) background dolls, too.

     Do you have the time and skill to hand pose and keyframe a doll's animation sequence?  No?  Then consider the huge leap you gain by being able to capture yourself -and perhaps a more graceful friend- with a Kinect and then apply the captured motions to Rex and Roxie (or whatever dolls you're using)!   Forget about gaming for the moment - imagine what you'll be able to do in Poser, animating any action you want.

     Do you want to render in other studios or with alternative render engines?  Consider the RAM/speed savings benefit of being able to bake the doll's entire array of textures to a single map.  And any engine which uses FBX (Unity, et al) can get a rigged and animated doll.  It's like PoserFusion to... anything.

     And don't limit your game thinking to making a new game;  what about making yourself a custom avatar for whatever game you already like?

Quote - Combining figures into one.
Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Most call that boolean.would be nice if all the cgi app's called everthing the same thing.

Boolean operations deal with intersecting volumes, combining two solids into one, using a solid to remove part of another solid, or to create a new solid from the intersections of more than one solid.

Poser clothing usually is not solid, and generally isn't supposed to intersect the underlying figure, except maybe the older clothing that had "capped" sleeves etc.

For Poser to remove e.g. the parts of the arm hidden by a sleeve requires an entirely different algorithm to determine the hidden part of the arm.  To call this a "boolean" operation would be incorrect as it is only similar in application.

Not into game development, but would love to see one of you make a game I would probably play endlessly....(your favorite legal for use female character) NITWAS :thumbupboth:

Seriously....you can't fault SM for trying to find new markets for their software can you?

Quote - Not into game development, but would love to see one of you make a game I would probably play endlessly....(your favorite legal for use female character) NITWAS :thumbupboth:

Seriously....you can't fault SM for trying to find new markets for their software can you?

I'm not faulting SM for trying to grow .
I hope there very very successful and have billions & billions to throw at Poser.
To make it all that much better for us.

I'm just confussed about what all there showing and saying on there game pages.

http://poser.smithmicro.com/gamedev.html 

http://poser.smithmicro.com/pproGameDev_specsheet_final_FULLRES.pdf 

Anyone correct me if I'm wrong but no one uses topology that's in those .jpgs.
Games don't use quad meshes,dynamic hair,cloths ,weight map rigs.

I just think that Game Poser pages and sell pitch could be a hole lot better.
Are they stricking you they know what there talking about ?

Quote - > Quote - Combining figures into one.

Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Most call that boolean.would be nice if all the cgi app's called everthing the same thing.

Boolean operations deal with intersecting volumes, combining two solids into one, using a solid to remove part of another solid, or to create a new solid from the intersections of more than one solid.

Poser clothing usually is not solid, and generally isn't supposed to intersect the underlying figure, except maybe the older clothing that had "capped" sleeves etc.

For Poser to remove e.g. the parts of the arm hidden by a sleeve requires an entirely different algorithm to determine the hidden part of the arm.  To call this a "boolean" operation would be incorrect as it is only similar in application.

What do we call it ?

The images at the Game Dev link do seem a bit puzzling.  The main male figure looks like a triangle mesh, presumably displaying the polygon feature in use, but the topology of the garment is... just weird.  My best guess is that the garment shows polygon reduction, but with subdivision applied on top of that.  The overall effect is puzzling, in a promotional graphic intended to illustrate the new feature sets.  :unsure:  Maybe someone will explain what the promo graphics are trying to illustrate.

The somewhat puzzling images aside, the feature descriptions seem pretty straightforward.  There's some good stuff there.  :woot:

Ya the black coat is a tri mesh that's been SubDed in to quads.
and the new tools sound cool.

none of the mesh is mirrored ,Does Poser have mirrored topology ?
not sure why the black coat collar is not just a plane.Does Poser have dobbled sided polygones ?
not sure why the white collar isn't just painted.
Why are the top of the shoulders next to the shirt have a rase in them like that ?
Why do we have alot of tri's at the deltoids biceps seem and fewer tris in the face.
Can we controal heavy lite sections of tri's ? 

The mesh in the .jpg is not ya standard game mesh.

Quote -
Anyone correct me if I'm wrong but no one uses topology that's in those .jpgs.
Games don't use quad meshes,dynamic hair,cloths ,weight map rigs.

Some game engines do use dynamic cloth. I don't know of any examples of dynamic hair yet. Unity3D and Unreal both use vertex weight painting (aka weight maps). Quad meshes are also useable, just not standard.

Quote - > Quote - > Quote - Combining figures into one.

Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Most call that boolean.would be nice if all the cgi app's called everthing the same thing.

Boolean operations deal with intersecting volumes, combining two solids into one, using a solid to remove part of another solid, or to create a new solid from the intersections of more than one solid.

Poser clothing usually is not solid, and generally isn't supposed to intersect the underlying figure, except maybe the older clothing that had "capped" sleeves etc.

For Poser to remove e.g. the parts of the arm hidden by a sleeve requires an entirely different algorithm to determine the hidden part of the arm.  To call this a "boolean" operation would be incorrect as it is only similar in application.

What do we call it ?

Unseen polygon removal?  That is the specific name of the feature.  I'm guessing it uses some kind of raycasting to determine if each polygon of a figure is obscured by any part of another figure, the computer equivalent of spinning the figure around and removing all polygons that can't be seen from any angle.

Quote - > Quote -

Anyone correct me if I'm wrong but no one uses topology that's in those .jpgs.
Games don't use quad meshes,dynamic hair,cloths ,weight map rigs.

Some game engines do use dynamic cloth. I don't know of any examples of dynamic hair yet. Unity3D and Unreal both use vertex weight painting (aka weight maps). Quad meshes are also useable, just not standard.

 

 

OK we need lots of info.
What games made with what engines on what plaforms have dynamic cloths ?
and how do they pull off such a resource killer ?
Do ya half to code in assembly ?

Quote - > Quote - > Quote - > Quote - Combining figures into one.

Example: You load a Figure, drag-drop-conform, some clothing over it, and then use the "combine" function to combine all these into a single rigged and posable figure.

Most call that boolean.would be nice if all the cgi app's called everthing the same thing.

Boolean operations deal with intersecting volumes, combining two solids into one, using a solid to remove part of another solid, or to create a new solid from the intersections of more than one solid.

Poser clothing usually is not solid, and generally isn't supposed to intersect the underlying figure, except maybe the older clothing that had "capped" sleeves etc.

For Poser to remove e.g. the parts of the arm hidden by a sleeve requires an entirely different algorithm to determine the hidden part of the arm.  To call this a "boolean" operation would be incorrect as it is only similar in application.

What do we call it ?

 

Unseen polygon removal?  That is the specific name of the feature.  I'm guessing it uses some kind of raycasting to determine if each polygon of a figure is obscured by any part of another figure, the computer equivalent of spinning the figure around and removing all polygons that can't be seen from any angle.

Well that's the good and bad things about PC's they don't think like we do.
Remember zBrush tri UVMaps ,always thought that was funny and a good exsample of the diffrences between us.

I know how I would go about getting all the meshes to merge
,have no idea if it would work thou.
I am curious to play with Game Poser ,
I am attempting to become a vendor and games mesh are right up my alley :)

Quote - Quad meshes are also useable, just not standard.

This depends on the target platform, and saying it is not standard is odd.

You should use a quad based mesh if you plan on texturing it with Directx Tesselation Shaders. Directx Tesselation doesn't have a clue what to do with a triangle unless it creates PNtriangles from a quad matrix list. (there are ways around this.) Using a non tesselated quad mesh also saves memory size and bandwidth between the cpu and gpu. The mesh is tesselated on the gpu, freeing the cpu from not only tesselating it, but transferring a larger mesh to the gpu.

Many game engines prefer, or convert to trianlges on import. This is a double edged sword depending on the target platform you are developing for. Or if you are texturing without uv maps (Ptex or similar).

If the engine you are using accels at using triangles, you don't want quads, no argument there.

If you are developing for a platform and using DirectX Tesselation Shaders, you don't want triangles. (again, there are ways around this. But why slow it down by using triangles?)

Which style gets used the most (Quads versus Triangles) is up for debate.

As far as dynamic cloth, most game engine use APEX (or similar as in Cry's case) style cloth with rope bones to define them. There not dynamic in they way Poser does it, they are rigged with physics applied to the bone chains. They look and react dynamic when played thou.

Quote - OK we need lots of info.
What games made with what engines on what plaforms have dynamic cloths ?
and how do they pull off such a resource killer ?
Do ya half to code in assembly ?

I don't know how it's coded, I just know that it is used, and it doesn't seem all that resource-intensive. 

SWTOR uses some type of dynamic/physics-based cloth for their cloaks and robes. 

Here is a video from CCP demonstrating the physX cloth that they were using in World of Darkness - the vampire MMO that was cancelled last year (or earlier this year)

http://www.youtube.com/watch?v=mrtwESnTOwY

Quote - > Quote - Quad meshes are also useable, just not standard.

This depends on the target platform, and saying it is not standard is odd.

Most game models for PCs and consoles consist of tris. Whether they were modeled as tris to begin with or teselated afterwards. That's all I was saying. Standard for most games is tris. 

http://www.youtube.com/watch?v=mrtwESnTOwY

I'm very impressed with the video.

CGI moves so fast it's difficult to keep up to date.
Guess I'm stuck in the past 2012 ya know ;)

maybe back around 1998 there where some meshes modeled with tri's.
but I would think most box modeled with loops then tried the mesh.

I can't say for everyone
but I think the best looking meshes are made in zBrush/MudBox
 ,then retopology.

So I guess that would make box modeling in quads or tri's old school.

Quote - Many game engines prefer, or convert to trianlges on import. This is a double edged sword depending on the target platform you are developing for. Or if you are texturing without uv maps (Ptex or similar).

If the engine you are using accels at using triangles, you don't want quads, no argument there.

If you are developing for a platform and using DirectX Tesselation Shaders, you don't want triangles. (again, there are ways around this. But why slow it down by using triangles?)

Which style gets used the most (Quads versus Triangles) is up for debate.

This is interesting.  Thank you.  While I was scripting with Panda3D, I was told that all video cards would necessarily break quads down into tris upon rendering, so I shouldn't be concerned that Panda was converting my quad .egg models into tris upon import.  From the way that was asserted, it sounded absolute, as though graphics cards only handle tris.  I suppose they were only thinking in terms of what Panda accommodates.  It's nice to know that some engines can do quads.

Quote - > Quote - > Quote - Most game models for PCs and consoles consist of tris. Whether they were modeled as tris to begin with or teselated afterwards. That's all I was saying. Standard for most games is tris.

The standard for rendering is triangles unless the engine and hardware does NURBS, etc (not much hardware does this, yet). But mesh storage is completely different story.

All Quad based meshes are technically made of triangles, but an edge is not drawn, or defined in the file. This has an advantage.

As an example.

Take a quad based mesh that is 600 polys and all quads.

This model has 2400 define vertices.

Now trianglulate the model. Now it has 1200 tris and 3600 vertices.

You just added 1200 vertices to the list in the file, which increases the file size dramatically. Keep in mind that the UV part of it increases in size as well, so does the normals section if it has to be in the file.

Do you need to store it as tris? Not really, all you did was dratically increase the overhead of everything done between the gpu, cpu, and memory of both.

1200 vertices in the example does not sound like much, but it all adds up very quickly in a multi player game with complex levels.

Use high rez meshes, and it gets far worse rather quickly.

If the game you are making can get away with using that much overhead (or requires it), by all means define the tris so it looks exactly like you want it to.

If you start running into bus flooding that degrades fps and game play, store them as quads and be done with it. Again this is engine specific, and many high end game engines are just fine with meshes stored as quads. So does DirectX.

Let the gpu do what it accels at, and feed it as fast as possible. You can feed it quads far faster than you could ever feed it triangles. If the engine supports processing quads, there is no reason to triangulate the mesh.

Since every quad mesh is made up of triangles behind the scenes, every quad mesh can be converted to triangles by revealing those hidden edges.  There's ways to do that automatically in 3dsmax, for example.  Therefor, modelling in quads for low poly game development is common practice.

Instead of decimating quad meshes, I would prefer an option to reverse subdivision.  Yes, it's possible to reverse subdivision once it has been baked in too.

http://www.mariussilaghi.com/products/turboreverse

It's just a math algorithm after all.  So this wouldn't destroy UV's in most cases, and allow you to maintain quad topology, even for background characters.  Triangulation is good for game engines, but if you have to then smooth it again, as in the example on the Smith Micro websites, to get a nice secondary character, then it's ONLY useful in game engines.

With decimation, I would worry about bad results with IDL, and strange things in animation.  Reduction by stepping down in subd levels is a cleaner way to reduce polys for background characters, and maintaining UV's, decent bending in animation,  etc.

Attached Link: Tomb Raider, Lara Croft...

Modeling in all quads and then just triangulating isn't the most efficient way of modeling for games. All you're doing is just doubling the geometry that you already have, instead of optimizing it. Triangulation should be done by hand to get the best results so you can reduce unnecessary geometry along the way. There are different ways depending whether you're modeling hard surface or organics.

An art test for most game studios will give you a concept piece and a poly count limit in tris. 7 to 10k is average for a fully dressed figure but the limits go up and down depending on who you ask. 

Modeling in quads, then revealing the hidden edges is very common practice in game modelling, because quads are easier to accomplish, and edit.  This technique only doubles the "faces", because verts are shared by edges, they don't get doubled.  Here's an example.

Above is a simple box made of quads.  Notice the statistics in the corner.

Only two additional verts were added to the geometry, but face count, of course, doubled.

I can tell you that a modded Skyrim can use HDT Physics for cloth simulation.  Bascially it is weighted using specific names and done in a certain way and you get: dynamic skirts, dynamic hair (in terms of flowing and moving), physics applied to body parts (jiggle, etc).  That doesn't mean dynamic cloth sims are directly translated to a game engine but games have their own ways to simulate it.  You'd likely still need to use the creation kit for that game to pull off the designs.

Poser Game Dev isn't going to Re-topo, which is what you'd want to change the flow of polygons.  It will be able to convert something to low poly and keep the body part and material divisions.  For the most part its going to decimate what is already there.  I haven't worked extensively with it to give very exacting information.

There will be a lot of non-game uses for this as well.  Crowd scenes has been cited for figure combining.  Mocap via Kinect for Windows will be a great boon for animating (also Kinect for XBOX can be done but not "officially" - I've done it, no rocket science).  Decimation will have other uses, like reducing the size of objects (or figures) with massive polycounts, plus it keeps morphs (if you want) -- reduce that 500,000 polygon car model to something reasonable, for example.

One could perhaps create some sort of LOD function for Poser, given Python access to the decimation tools.  There's some good potential there.

Take a quad based mesh that is 600 polys and all quads.
This model has 2400 define vertices.
Now trianglulate the model. Now it has 1200 tris and 3600 vertices.

Quote - TressFX used on Lara Croft's hair in the latest Tomb Raider sounds like strand based physics.

Wicked video

Quote - Modeling in all quads and then just triangulating isn't the most efficient way of modeling for games. All you're doing is just doubling the geometry that you already have, instead of optimizing it. Triangulation should be done by hand to get the best results so you can reduce unnecessary geometry along the way. 

alot just quad retopolgy don't bother to tri just decimate polycount ,
decimate polycount will auto tri's the mesh.

best way ,probably not.fastest easiest way ,ya.

it's all about time and money

Quote - Take a quad based mesh that is 600 polys and all quads.

This model has 2400 define vertices.

Now trianglulate the model. Now it has 1200 tris and 3600 vertices.

You just added 1200 vertices to the list in the file, which increases the file size dramatically. Keep in mind that the UV part of it increases in size as well, so does the normals section if it has to be in the file.

I am confused here...  A quad has four vertices.  If I split it into tris, doesn't it still only have four vertices?

I thought that was the point of tri-strips, to build each triangle by adding one vertex to an existing triangle...

There should not have been any additional verts created in the cube example above. Triangulating a mesh does not change the number of verts because all you're doing is dividing a quad in half diagonally. If the mesh is not all quads, then there might be some increase in vert count depending on whether or not existing tris are ignored. Mostly the increase will only be in the number of edges and faces. 

The reason I prefer to triangulate by hand is because you have more control of edgeflow and poly count. There are a lot of instances where a tri can be used in place of a quad to help reduce innitial geometry. So I model in mostly quads at the lowest res necessary (my build mesh), to get the base shape and then sub divide for all quads and reduce where necessary. This will turn my build mesh tris into 3 quads each, where as had I used a quad instead of a tri, i would have 4 smaller quads. Auto triangulation usually ignores those contours or gets them wrong half the time. Doing it all by hand is pretty quick on low poly models anyway since you're working with pretty low poly counts to begin with, and only have to worry about half of that. I'd rather spend an extra 20 minutes triangulating the way I want it to be and spare a few dozen to a few hundred polys (or more) in the process. 

the cube ended up with 10 verts
cause for some reson only 1 of 3 vertices of one of a tri attached and 2 vertices are not attached to the cube
if ya subD the mesh ya might see it

ya half to be careful LW,C4D double edges don't show even with SubD's

I agree ,buy hand topology is better then auto tri,desimate.

I like this thread I'm getting cault up on all the curent tools.
be cool if GAME Poser inclued the wicked tools also :)
I'm all for real time dynamics for Renders,Video's,Games.etc etc

Quote - the cube ended up with 10 verts
cause for some reson only 1 of 3 vertices of one of a tri attached and 2 vertices are not attached to the cube
if ya subD the mesh ya might see it

Yes, that is true.  I inadvertently created an additional double-vert by cutting manually.  That's the problem with manual triangulation.  When I used the automatic hidden edge feature, I ended up with only 8 verts, exactly what I began with.  My point remains, that triangulation of the quad mesh did NOT double everything on the model, as someone previously alluded to on the first page of this thread..

As we know, a game engine counts triangles, not polygons.  A polygon can be a face containing 3, 4, 5, 6, etc. sides.  Splitting a quad will not increase the number of triangles, or verts, on a model.

Game Poser appears planned to have all of the Poser Pro tools plus the GD ones.

Quote - As we know, a game engine counts triangles, not polygons.  A polygon can be a face containing 3, 4, 5, 6, etc. sides.  Splitting a quad will not increase the number of triangles, or verts, on a model.

I should have explained it a tad further.

The number of triangles and vert does not increase, but the number of times the are defined in the file and called during construction does. Defining the triangles in the matrix increases the size of it. There is no magic here. If it is there, the matrix must define the winding order.

Consider a cube that is all polygons. Each vertex in that cube is called 4 times during the construction of the matrix in memory. Depending on how it is trangultaed, some of the vertices will be called up to 6 times during the construction. Yep, it is still exactly the same number of vertices, but there is now more information to send to the GPU.

If you can get away with it, send it to the gpu as quads. 

Will my mesh be triangled or do I have an option? I don't develope games, but I'd like to figure out, how I can benefit from those new GD-features.

Poser does not care too much if it is in tris or quads, as long as the mesh is properly build..

The most asked question in the coming weeks will be:
Why do I get cracks, or weld cracks?

The common answer will be : Are all the bits and pieces welded or unwelded?

Most "game" stuff is unwelded.

And what does Poser need? Correct. Poser needs welded files.

Be it for the clothing room, for the fitting room, or for the newer Game functions, Poser is at its best with properly grouped and welded files.

where excluding DAZ Studio from this.I know where the $$$ comes from.

How does free app companies like blender etc etc stay in business ?

Attached Link: http://www.blender.org/foundation/

It's a nonprofit organization, established for the sole purpose of making the Blender app. The app came first. The foundation to help it came later. It does not "stay in business" as you put it. As a business, it is a complete failure.

ok let me ask this way ,how do they make money at it ?

Quote - ok let me ask this way ,how do they make money at it ?

They don't actually make money.   It's funded through donations, and from their own pockets usually.

Quote - > Quote - How does free app companies like blender etc etc stay in business ?

It's a nonprofit organization, established for the sole purpose of making the Blender app. The app came first. The foundation to help it came later. It does not "stay in business" as you put it. As a business, it is a complete failure.

I'll grant that it wasn't successful as shareware and was a failure as a commercial app.  But it appears to be thriving as an open source app.  Isn't the open-source model based on paying the foundation/community for support and specific development requests?  If it can succeed as a longterm viable tool while failing as a business, then I do agree with you.  

Where kinda stuck on blender and thats allright but there's a lot of free apps.
Aren't they exspecting to make a profit at some time ?
By adventualy selling the app when it's good enought ,add's ,something ,anything ?
Why would anyone worry with a business that's a complete failure there hole lifetime ?
and how could ya pay the bills like that.there's got to money some where ,don't there ?

Quote - Where kinda stuck on blender and thats allright but there's a lot of free apps.
Aren't they exspecting to make a profit at some time ?
By adventualy selling the app when it's good enought ,add's ,something ,anything ?
Why would anyone worry with a business that's a complete failure there hole lifetime ?
and how could ya pay the bills like that.there's got to money some where ,don't there ?

 

The open source business model just works differently.  In theory you give the program away, and the community improve and refine it until it gains some kind of traction or niche.  Then rather than buying the program outright, users fund development by contracting specific developers or contributors, whether paying them as consultants or to fund specific developments.