I've been thinking about this for a few weeks so I'll pose this question for you all:

Instead of being incrementally updated, should the next full version of poser be rebuilt from the ground up?    Basically take it apart to see what code/features work right, keep those and fix or rewrite everything else.

it would be nice. but we've already seen what happens. look at Daz Studio. it arrived a year late, still has problems with handling poser items. now, it took 2 years to get to Alpha..... thats a lot of investment with a product if it's not bringing in money with new versions...

I think they are rebuilding it (the library, the interface) but by small stages. Scares away current users less and allows them to continue regular releases ;o).

Laurie

I just hope the material room is next.

Quote - I just hope the material room is next.

You do? But you're the material room master...lol.

Laurie

Quote - I just hope the material room is next.

I'm right there with you, BB, because that's where I spend most of my time in Poser now.

Poser needs to be especially to run correctly in a 64-bit environment instead of patches of 64-bit codes into an out dated 32-bit core program. But, it will not happen if is so it will be done over a period of time within releases as LaurieA  said this way it doesn't scare anyone off.

just give me subsurface scattering. i dont care what kind of SSS.... jsut something.

i dont care if it renders 5 hours. but please i beg you

`I'm very pleased with Poser 8/Pro upgrade compared to Poser 7 after Poser 6 for example. The have actually made considerable changes and improvements. It's the most stable version of Poser I've worked with, so I wouldn't mind if they keep the same update model.

What I'd really like to see changed next is the camera and general 3D navigation system, If you use Wings, Blender or 3dsmax for a few minutes it hurts going back to Poser. Scene management could use an upgrade too, implementing grouping and layers.

Loaded question to BB!
What would you specifically want added to the Material Room? (Refresh the memory of us old folks :biggrin: )

Quote - What I'd really like to see changed next is the camera and general 3D navigation system, If you use Wings, Blender or 3dsmax for a few minutes it hurts going back to Poser.

hm does this just mean how you do it, or the responsiveness/control?

I always think something is wrong with my P7 but I'm not sure

You know, zoom in and out with the mouse wheel, rotate with the mouse (current poser implementation rotates around the Z axis too, making it useless), pan, zoom extend, etc.

I'm going beyond that and suggesting that the way we create models gets changed too.  No sense in changing the software if we're going to have the same ole types of models.

Musculature, physics, you know...reality in a box. 

Right now, I'll just settle for 64-bit crunchiness throughout & a really good set of tutorials on the new features added to P8/PP2010.

*Quote - "I just hope the material room is next."

*yup yup

Quote - Loaded question to BB!
What would you specifically want added to the Material Room? (Refresh the memory of us old folks :biggrin: )

So many things. Let's start with the fundamental premises.

Parameter nodes - I should be able to place parameter nodes in a shader that are recognized as such. These would be presented in the  material room as dials and color patches on a Material Parameters tab. Nobody should have to poke around in the advanced material room if they just want to use a shader. The settings of these should be able to be saved in a new library file as presets, so users can mess with parameters and save them, not save the whole material collection. Then they could try different shaders, but re-use the same parameters. For example - suppose you have 3 different skin shaders, and lots of different colors and shine settings, and you want to try out all three shaders with all your preset parameters. First-class material parameters would let you do this with very few clicks.

The next one is to deal with complexity. There should be a Composite Node. This is a technique I use in all the software I write that is to be used by humans. It is like an integrated circuit. Inside, there is a shader but no surface. Outside there are just inputs and outputs. At the boundary, you connect the IO pins on the outside and the inside to other nodes. The insides never need to be looked at by people who use them. Composite nodes should be in the library and can be loaded as if they were built-in nodes.

Any composite node that has parameters inside should expose them on its outside as editable parameters, just like nodes do today. If there was such a thing in Poser, I'd take my 14-node true Fresnel reflection sub-shader and make it a single node for everybody to use. Then you would not need matmatic just because you want realistic reflections.

Texture assets (color map, bump map, etc.) should be separated from the shader nodes. A material should consist of texture assets and a shader, specified on separate tabs. I should be able to replace the textures while keeping the shaders, or replace one or more shaders while keeping the textures.

So I'd like to see a node called "Texture_Map", to replace Image_Map. It should not have a file name. Instead it should have a property name, such as "Diffuse Color" or "Bump", that I can type in. Perhaps also there should be a few standard derivatives of this with hard-coded names such as Diffuse Color, Diffuse Value, Bump, Displacement, Specular Color, Specular Value. These standardized names would promote the correct placement of images into a texture set. In addition, it would have all the other properties that are already on Image_Map, but with a twist. The actual value can be overridden or combined in the Textures tab. This way, you can set up the scale of a tileable texture independantly of the shader.

In the "Textures" tab, you'd load up Diffuse Color, Bump, and so on as needed. The Texture_Map node in the shader would not care what the file names are. It would only care that it connects to the Color map, the Bump map, etc. For each texture, it should also offer (as an advanced option) settings for U_Scale, V_Scale, tiling mode, etc - most of the stuff that is in the Image_Map node. The final effective scale would combine the scale in the Texture_Map node with the scale in the Textures tab by multiplication. Most of the time, both would be 1. Maps used for data should have value scaling and offset - particularly bump and displacement maps. So you can set the middle gray to mean "no change" like all the other apps in the universe, and then adjust the amount of bump or displacement without poking around inside the shader.

This alone is worth an upgrade. If this was the only improvement, I'd be all over it. It means that people can load a shader once, and then play all day trying it out with other texture sets. They would not need VSS to re-apply the shader when switching textures. Or - they could try out different shaders while keeping the textures. Either way, no more need for VSS, at least for this purpose.

There is another thing VSS does that could be built-in - that is to put materials into groups. We need two kinds of groups: shader groups and texture groups.

A shader group let's us ignore the fact that there are 14 skin zones. We can define a "Skin" group, put the 14 material zones into it, and then we only have to load or edit one shader to change how the skin looks.

Shader groups that span multiple props and figures would be even cooler. You have 8 dining room chairs. You want them all the same, but you keep adjusting the shader. Do you like doing that 8 times? No. You want one shader for all 8 chairs.

Similarly, many figures have multiple material zones that need the same textures - they are UV mapped onto the same instance. So a texture group would take care of that. For example, unless you want two different eye colors, it would be great if there was a Texture Group eye = [left_iris, right_iris, left_cornea, right_cornea, left_pupil ...]. See what I mean? I don't want to load the fricking eye texture into 10 materials - just one. I don't want to load the body skin and body bump into 14 places - just one.

With this second addition, VSS goes away completely.

Notice that so far I haven't talked about new node capabilities. This is simply re-organizing how materials and textures are represented in a data model that is far more convenient.

But for real new nodes:

SSS node - a real one, not useless like FastScatter.

Refract2 - a better Refract that understands that you can enter and exit a surface and that the bend angle is opposite when that happens. Also should understand something about scattering (decreasing luminance based on distance travelled.) Even better would be if it did volumetric sampling. Ever try to make a real-looking marble? (not the material, but the glass toy used in children's games) Can't be done with a simple sphere.

If SSS is not reasonable, then I want:

Ray Distance - let me launch a ray and tell me how far the ray went before it hit another surface. Let me qualify this with whether or not the surface hit has to be from the same material and/or actor as it is starting from. With this I could fake SSS somewhat. Maybe a variant could include the ability to launch a bunch of rays and combine the distances found using a user-supplied function: examples of useful ones would entail mean, average, max, min, gaussian, cosine, etc. Perhaps also a measure of standard deviation would be useful. This would require two outputs from one node - something Poser can't do today.

So let's add that - allow a node to produce multiple outputs.

• Data I need to do interesting things:

Camera Position (where is the camera)
Camera Direction (which way is it pointing)
Camera Vector (which way to the camera from where I am)

• Data I need to do better procedural textures:

Model P (coordinate of the object in model space, not world space: options to including scaling or not, rotation or not, etc.)
Model N (model space surface normal direction, not world space: similar options as Model P)

(If I had Model P I could do procedural stockings. If I had model N I could do procedural suntan. If I had both, I could do procedural ethnic variations of skin.)

I also want an option to use world-space, model-space or UV(W) texture space for every node that generates any sort of pattern, such as Cellular, Fractal_Sum, etc. Textures are usually two-D, but geometry can have not just U and V, but also W coordinates. This would allow the possibility to define a path through a virtual space. That virtual space defines a 3D pattern. The UVW coordinates cut out from that 3D pattern.

I'd want a W node.

If that is too much, then I really want this node:

Actor Scale node - a node that tells me how the object was scaled in X, Y, and Z.

The most prominent example of what I could do so much better with these coordinate space solutions is wood. Today, if I make a procedural wood shader based on UV coordintes for a generic box, and you stretch the box, it the texture stretches instead of revealing more wood. If I had Model P that would no longer be a problem. There are other interesting cases.

For example, suppose you put a tiling wallpaper on a one-sided square. You scale the square to make a wall. What happens to the texture? It stretches with the UV space. I would solve that by changing the U_Scale and the V_Scale to match the Prop Scale in X and Y. Problem solved without issues.

====

I have many more but these are key.

There should be a Composite Node. This is a technique I use in all the software I write that is to be used by humans. It is like an integrated circuit. Inside, there is a shader but no surface. Outside there are just inputs and outputs. At the boundary, you connect the IO pins on the outside and the inside to other nodes.

kind of a container? open it up, pop the nodes in that do a specific job, say calculate a zebra pattern, then you just button it up with just the inputs (say colours) and the output, and that's all the user sees? I can see that working and if you were to add a password to it so the node could be locked...

Yes, Kai - that's exactly it.

I implemented an incredibly complicated node system at a prior company. We used nodes to do data manipulation. The primitive nodes did things like sort, filter, count, etc.

People with ordinary Excel-type skills would assemble nodes to do complicated things. When things got too complicated, or they wanted to share, they would make composite nodes. The program easily handled 5000 nodes in one "shader". It was amazing.

People with no programming skills whatsoever would rely on others to create new complicated features by assembling existing nodes. Then they would use them, completely ignorant of any of the math and with a single click to create. I saw some composite nodes with over 800 steps inside, and near-morons would routinely wire them up to answer complicated business questions.

Get SALES data -> Group by Region -> Find average per group -> Find Salesmen with X% below average sales for the group -> Generate list of people to fire.

I'm kidding about that last step.

What it was usually used for was revenue assurance - making sure you charge for every product or service you delivered. Or cost assurance - making sure you got what you paid for. Or inventory reconciliation. Or order quality management.

Ever time somebody orders any service from Comcast, they go through my nodes.

Every time somebody makes a phone call on Verizon, they go through my nodes.

Every person in Belgium goes through my nodes.

hmm throw in support for IES Lighting parameters....

Speaking of IES, I've been meaning to make a thread about light shaders. I have some cool stuff to show. And since I released matmatic 1.1, everybody can make complicated light shaders with a few lines of script.

I haven't done an IES light interpreter, but I have done a bunch of spotlight shaders that don't have the regular cone falloff. I have all sorts of shapes you can project without having to resort to gels.

I am so glad I asked.
That functionality sounds really fun to play with. And I'm all for saving on the "clicking"!

Would this New Material Room be able to rock (the current) Firefly or would a plug-in (ala the LuxRender thread) to an external renderer or exporter to Bryce/Vue/etc be preferred as per the OP's original question. Would you want a Firefly II (of Firefly plus) to leverage this dream Material Room?

I really like Poser Pro 2010 but what I still miss is...

The materials that I click for each figure or prop in the Material Room are in a vertical not horizontal list - why? And if there are 50 plus materials per prop (for example those free cars) in that list it's unnerving to always scroll again from beginning to the specific one towards bottom. Can this be changed? Please!

Also if you want to save a prop you have to click most items manually in that little window that opens and whose size is not changeable. It's not possible to select them all or unselect them all in the check box. This seems to  to work only with characters via clicking 'body'.

(Resume Rendering would be great of course but I think above wishes are easier to work on.)

Quote - I am so glad I asked.
That functionality sounds really fun to play with. And I'm all for saving on the "clicking"!

Would this New Material Room be able to rock (the current) Firefly or would a plug-in (ala the LuxRender thread) to an external renderer or exporter to Bryce/Vue/etc be preferred as per the OP's original question. Would you want a Firefly II (of Firefly plus) to leverage this dream Material Room?

Much of what I described (Texture Map nodes, Composite Nodes, groups, etc.), would require no changes to the renderer. They are changes to the shader data model and UI, but they translate into directly into the existing non-composite shader model.  That's how I introduced composite nodes into my previous company's product. It started with a flat node diagram with no structure. Adding the composites required no changes to the back-end.

The net effect is the same.  I had hoped to build all that into matmatic (with a GUI) by now, but I'm too busy with work.

Some of the others, like the model space coordinates, would not be so minor. Refract2 is minor - the math is a straightforward variation on what is already there. Stefan knows better what is easy versus what is hard.

Firefly is capable of quite a few more add-ons, but will never perform super fast unless we give up the total freedom we have with the lighting nodes. Instead, there has to be a commitment to realism, and only use shader models that do not violate the laws of physics. Which is what LuxRender is trying to do. It will not offer impossible materials. But it does have some ability to create procedural patterns. Lux needs a lot more of those types of things - procedural pattern generation to affect specularity, diffuse color, etc.

GPU accelerated rendering is a must for the next version of Poser, I know it's hopefully going to be available to us shortly but it really needs to be "as standard" for the next version.

Quote - I just hope the material room is next.

Hear-hear. Stating the obvious: "especially if you're involved".

Quote - GPU accelerated rendering is a must for the next version of Poser, I know it's hopefully going to be available to us shortly but it really needs to be "as standard" for the next version.

LOL !!
IES Light support??
GPU rendering??.

Hmm... Cinema4D Studio  Cost over $3000 and we still had to by Vray to get IES lights support.

MODO401 cost about $900 USD and has IES Lighting Support
and a Great Preview render with GI& SSS in the preview.

Such features in a "rebuilt from scratch" poser would send the
the price up way beyond the $250-300 that most user here demand.

Cheers

oh damn. so I should have paid more than $50 for trueSpace 5.2 that has IES support in it......

"***oh damn. so I should have paid more than $50 for trueSpace 5.2 that has IES support in it...... "

No Sir
you should have paid whatever "caligry" thought was a marketable price.
And how relevant is  your $50 truespace today? ...any updates??

Oh wait it was sold to MS and promptly killed ,IES light and all.

I doubt anyone here belieive poser will actuallly become Cheaper  if  a
built from Scratch Version had the aformentioned features.

Cheers

hey. don't you go calling me names. no one calls me 'sir' ..I work for a living.

No but I bet adding GPU support would require a hell of a lot of rework to try to make Firefly run on it. I don't think that's how it will happen...

LuxRender is free & will shortly have GPU rendering built in, scripts are in the works for both Daz Studio & Poser. Not built in I know but at least it's a start & it won't cost an arm & a leg either.

yeah I can imagine DS/Poser going in that direction more easily than trying to make their existing renderers work on GPU.

Ow! bagginsbill makes my pointy head hurt.
And yes, Poser does need to be streamlined to make it look and work like a modern program, instead of a retread of something ten years old.
But it should also be cheaper, under fifty dollars if possible, and be a perfect release requiring no service packs or patches. A complimentary box of Raisinettes included in the packaging would be a nice touch too.

Quote - > Quote - Loaded question to BB!

What would you specifically want added to the Material Room? (Refresh the memory of us old folks :biggrin: )

So many things. Let's start with the fundamental premises.

Parameter nodes - I should be able to place parameter nodes in a shader that are recognized as such. These would be presented in the  material room as dials and color patches on a Material Parameters tab. Nobody should have to poke around in the advanced material room if they just want to use a shader. The settings of these should be able to be saved in a new library file as presets, so users can mess with parameters and save them, not save the whole material collection. Then they could try different shaders, but re-use the same parameters. For example - suppose you have 3 different skin shaders, and lots of different colors and shine settings, and you want to try out all three shaders with all your preset parameters. First-class material parameters would let you do this with very few clicks.

The next one is to deal with complexity. There should be a Composite Node. This is a technique I use in all the software I write that is to be used by humans. It is like an integrated circuit. Inside, there is a shader but no surface. Outside there are just inputs and outputs. At the boundary, you connect the IO pins on the outside and the inside to other nodes. The insides never need to be looked at by people who use them. Composite nodes should be in the library and can be loaded as if they were built-in nodes.

Any composite node that has parameters inside should expose them on its outside as editable parameters, just like nodes do today. If there was such a thing in Poser, I'd take my 14-node true Fresnel reflection sub-shader and make it a single node for everybody to use. Then you would not need matmatic just because you want realistic reflections.

Texture assets (color map, bump map, etc.) should be separated from the shader nodes. A material should consist of texture assets and a shader, specified on separate tabs. I should be able to replace the textures while keeping the shaders, or replace one or more shaders while keeping the textures.

So I'd like to see a node called "Texture_Map", to replace Image_Map. It should not have a file name. Instead it should have a property name, such as "Diffuse Color" or "Bump", that I can type in. Perhaps also there should be a few standard derivatives of this with hard-coded names such as Diffuse Color, Diffuse Value, Bump, Displacement, Specular Color, Specular Value. These standardized names would promote the correct placement of images into a texture set. In addition, it would have all the other properties that are already on Image_Map, but with a twist. The actual value can be overridden or combined in the Textures tab. This way, you can set up the scale of a tileable texture independantly of the shader.

In the "Textures" tab, you'd load up Diffuse Color, Bump, and so on as needed. The Texture_Map node in the shader would not care what the file names are. It would only care that it connects to the Color map, the Bump map, etc. For each texture, it should also offer (as an advanced option) settings for U_Scale, V_Scale, tiling mode, etc - most of the stuff that is in the Image_Map node. The final effective scale would combine the scale in the Texture_Map node with the scale in the Textures tab by multiplication. Most of the time, both would be 1. Maps used for data should have value scaling and offset - particularly bump and displacement maps. So you can set the middle gray to mean "no change" like all the other apps in the universe, and then adjust the amount of bump or displacement without poking around inside the shader.

This alone is worth an upgrade. If this was the only improvement, I'd be all over it. It means that people can load a shader once, and then play all day trying it out with other texture sets. They would not need VSS to re-apply the shader when switching textures. Or - they could try out different shaders while keeping the textures. Either way, no more need for VSS, at least for this purpose.

There is another thing VSS does that could be built-in - that is to put materials into groups. We need two kinds of groups: shader groups and texture groups.

A shader group let's us ignore the fact that there are 14 skin zones. We can define a "Skin" group, put the 14 material zones into it, and then we only have to load or edit one shader to change how the skin looks.

Shader groups that span multiple props and figures would be even cooler. You have 8 dining room chairs. You want them all the same, but you keep adjusting the shader. Do you like doing that 8 times? No. You want one shader for all 8 chairs.

Similarly, many figures have multiple material zones that need the same textures - they are UV mapped onto the same instance. So a texture group would take care of that. For example, unless you want two different eye colors, it would be great if there was a Texture Group eye = [left_iris, right_iris, left_cornea, right_cornea, left_pupil ...]. See what I mean? I don't want to load the fricking eye texture into 10 materials - just one. I don't want to load the body skin and body bump into 14 places - just one.

With this second addition, VSS goes away completely.

Notice that so far I haven't talked about new node capabilities. This is simply re-organizing how materials and textures are represented in a data model that is far more convenient.

But for real new nodes:

SSS node - a real one, not useless like FastScatter.

Refract2 - a better Refract that understands that you can enter and exit a surface and that the bend angle is opposite when that happens. Also should understand something about scattering (decreasing luminance based on distance travelled.) Even better would be if it did volumetric sampling. Ever try to make a real-looking marble? (not the material, but the glass toy used in children's games) Can't be done with a simple sphere.

If SSS is not reasonable, then I want:

Ray Distance - let me launch a ray and tell me how far the ray went before it hit another surface. Let me qualify this with whether or not the surface hit has to be from the same material and/or actor as it is starting from. With this I could fake SSS somewhat. Maybe a variant could include the ability to launch a bunch of rays and combine the distances found using a user-supplied function: examples of useful ones would entail mean, average, max, min, gaussian, cosine, etc. Perhaps also a measure of standard deviation would be useful. This would require two outputs from one node - something Poser can't do today.

So let's add that - allow a node to produce multiple outputs.

• Data I need to do interesting things:

Camera Position (where is the camera)
Camera Direction (which way is it pointing)
Camera Vector (which way to the camera from where I am)

• Data I need to do better procedural textures:

Model P (coordinate of the object in model space, not world space: options to including scaling or not, rotation or not, etc.)
Model N (model space surface normal direction, not world space: similar options as Model P)

(If I had Model P I could do procedural stockings. If I had model N I could do procedural suntan. If I had both, I could do procedural ethnic variations of skin.)

I also want an option to use world-space, model-space or UV(W) texture space for every node that generates any sort of pattern, such as Cellular, Fractal_Sum, etc. Textures are usually two-D, but geometry can have not just U and V, but also W coordinates. This would allow the possibility to define a path through a virtual space. That virtual space defines a 3D pattern. The UVW coordinates cut out from that 3D pattern.

I'd want a W node.

If that is too much, then I really want this node:

Actor Scale node - a node that tells me how the object was scaled in X, Y, and Z.

The most prominent example of what I could do so much better with these coordinate space solutions is wood. Today, if I make a procedural wood shader based on UV coordintes for a generic box, and you stretch the box, it the texture stretches instead of revealing more wood. If I had Model P that would no longer be a problem. There are other interesting cases.

For example, suppose you put a tiling wallpaper on a one-sided square. You scale the square to make a wall. What happens to the texture? It stretches with the UV space. I would solve that by changing the U_Scale and the V_Scale to match the Prop Scale in X and Y. Problem solved without issues.

====

I have many more but these are key.

Quote - What I'd really like to see changed next is the camera and general 3D navigation system, If you use Wings, Blender or 3dsmax for a few minutes it hurts going back to Poser. Scene management could use an upgrade too, implementing grouping and layers.

I'd like to see them allow rotation relative to the scene as well as the object's own axis.

Just say something isn't possible in Poser, and I can't help but look into it.

I would have done it much quicker but it took me a long time to understand the IES spec. The script is actually only about 40 lines of code.

starts digging out his list of IES light sets download sites

Quote - I now have IES lights working in Poser. This will work in any version since Poser 5. It's a matmatic script that reads an IES file and generates a Poser light shader with math nodes that implements what is in the file.

Just say something isn't possible in Poser, and I can't help but look into it.

I would have done it much quicker but it took me a long time to understand the IES spec. The script is actually only about 40 lines of code.

I guess you've been called a genius already? ;o).

Laurie

I'm using these. There's a TON of them in there.

http://rapidshare.com/files/116873427/Lithonia_Lighting.zip.html

lol.  :)

I'm not sure what an IES light is, but it looks nice.

Get this, too. It's very nice for browsing the hundreds of lights you have. It will do a preview render of any light instantly as well.

http://www.photometricviewer.com/

Quote - lol.  :)

I'm not sure what an IES light is, but it looks nice.

IES = Illuminating Engineering Society.

And it's a file format.

The IES organization established a standard for manufacturers to document how their lights behave. These documents are used in high-end 3D visualization of lighting arrangements, in high-end packages like Max.

The manufacturers want you to buy their lights, so they publish settings for free. Which means there are literally thousands of pre-configured lights - all you gotta do is import them.

Poser users could not do this - until today.

I still have a few things to work out before I publish a new freebie.

Also, the IES file format has several variants. I've only dealt with one of them. Also, I have not dealt with asymmetrical lights yet. That will be a little bit tricky. So far I'm only dealing with round ones - ones that don't look different if you spin them.

Wow, that browser looks handy. Thanks for the link :o).

Laurie

(Looks like I accidentally grabbed the wall and moved it.)

So, do these lights have the falloff and stuff built into them? Or does Poser still control that?

Laurie

Poser is doing the distance falloff. The shader is doing the falloff with angle.

pardon, but does that mean that those of us who haven't been able to upgrade to P8 and use material falloff and linearization can't use these?  i already have inverse square and linear falloff Matmatic functions for my lights.  would your implementation make it possible to combine those?

wait, i see you're adjusting color.  i can definitely make this work with my falloff (which affects intensity).  and i'm not too concerned with color, because i don't really use gels and can kind of eyeball basic light color most of the time.  but i'll post just to shout out for us non-PP2010 users.

You can combine this with the shader-based distance falloff as well. I just didn't bother at the moment.

I'll give you the script.

Do you want it right now as is?

Quote - Poser is doing the distance falloff. The shader is doing the falloff with angle.

Hmm...interesting (and nice ;o)).

Laurie

oh, i can definitely wait.  and i don't need you to combine it, per se.  i was more thinking about the ability to use it with the scripts i already have, and i know you don't usually make stuff to work with other people's scripts.  and since this sounds more complex than your average Matmatic script, it thought you might make this all compiled.   or something more closed.

IES lights in poser just like that?

for the love of god will SM already give BB SSS.

this guys every week prooves what he can do. why is it so hard? why is it sooooooooooooooooooooooooo hard?

: - )