Jump to content
  • Advertisement

How to look hot at 30? A Sprint 30 reports!



Today starts our new sprint 30. During the last sprint, we did get much work done. 😊

We can’t publish that much pics these days, since we don’t want to spoil the new video scenes.

But, I tell you something. 😄

We finished modeling all objects for the kitchen, also for Clearwaters home-office and main hall.

We offer you a lil’ glimpse 😉:


We need more special textures for some of these objects. It’s a work item for the current sprint.

We designed furniture and had fun.

We finished texturing some houses from Clearwaters world-outside. We’ve to continue, anyway.

We finished modeling all animations relevant for the new video as listed in the script from the last sprint. We made a first-scene animation where he realizes something is weird. We modeled a look-out-of-the-window animation, a looking-around animation, a sneak-animation, and so on.

We also modeled several facial animations for the above-mentioned body animations. Some new faces can look left, right, up and down, etc. Clearwater is therefore able to move his eyes and to blink. But we still need to test ALL of these newly created animations in the current sprint.

Now, we can throw all necessary-for-the-new-video ingredients in a big bowl. It’s our mission henceforth to make a tasteful soup out of it. How euphemistic!

We want to start creating some video sequences, i.e. positioning the cameras in Clearwaters apartment, set light, test all animations, fix all Bugs and issues, adapt Clearwaters appearance, and make everything looking good. After having eaten all Bugs, the video is ready for YouTube.

Furthermore, we modeled a hot animation for Clearwaters full body 4K Pic. It’s supposed to be a promotional pic that will appear on social media and on our new game blog as appetizer. 😉

During the current sprint, we want to test and render the pic of him, just minutes before we publish it.

 This week, I swear, I’ll continue writing the book BIZARRE Episode I!

Charly Men’s website charly-men.com gets a new design, too. Our software developer started writing code. I get my own new Content Management System called BeeMS.

Don’t ask me why it is so called. 😛

The new game blog for BIZARRE is included in the charly-men.com website as it is now. The Charly Men website get’s expanded and will later include the Charly Men’s BIZARRE game blog, all Charly Men’s books, paintings, lyrics and songs. It gets published hopefully before the sun used up all its helium.

I sum all up:

We want to texture houses and objects in the apartment.

We want to create some video sequences to test all animations and textures.

We want to fix all issues and Bugs seen during the video sequence tests.

We want to continue writing the book BIZARRE Episode I.

We want to render a nice 4K Pic of Clearwater and publish it.

We want to continue programming the new Charly Men website as well as the new game blog.


I have a great appetite for soup now!



Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • What is your GameDev Story?

    In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

    (You must login to your GameDev.net account.)

  • Blog Entries

  • Similar Content

    • By maxmaxmax
      I have a bitmap file that I created in photoshop that contains an alpha channel. When I try to use texconv to create the texture, the resulting texture only contains a fully white alpha channel instead of the alpha channel that I created in photoshop. The arguments that I passed to texconv are:
      -f BC3_UNORM .\cat_bmp.bmp -dx10 -y the output from texconv is this message:
      reading .\cat_bmp.bmp (600x400 B8G8R8X8_UNORM 2D) as (600x400,10 BC3_UNORM 2D α:Opaque) writing cat_bmp.DDS I find it suspicious that the output says that it`s reading alpha as "Opaque" since the result I get is an alpha mask that is fully white... which sounds like what the output means by an "opaque" alpha.
      What could be causing my alpha channel to turn all white?
    • By badapple0028
      In DCC, we can soft select things with proper falloff in volume/viewport. I think I can do the soft selection with viewport falloff. But how is volume falloff implemented especially with lasso/poly selection mode?
      In lasso/poly selection mode, the 2D selection area in viewport is irregular polygon. Then selected objects will also in an irregular 3D space. How to do volume falloff based on this irregular 3D space to achieve soft selection?
    • By Discip13
      Hello everyone! My name is Nikita Yashukov. I'm a 3D Artist looking for projects to participate. I have been creating 3D stuff for about two years and I'am interested in teamwork experience.
      You can see my works here: https://www.artstation.com/lof
      My contacts: shvartznik@gmail.com
      Thank you.

    • By calioranged
      *** Beginner question - some terminology may not be correct ***
      I will relay my understanding of OpenGL shaders in this post in the hope that members can confirm the areas where I am correct and redress the areas where my understanding falls short.
      Firstly, here is my shader:
      #shader vertex #version 330 core layout(location = 0) in vec4 position; layout(location = 1) in vec2 tex_coord; out vec2 v_tex_coord; void main() { gl_Position = position; v_tex_coord = tex_coord; }; #shader fragment #version 330 core layout(location = 0) out vec4 colour; in vec2 v_tex_coord; uniform sampler2D u_Texture; void main() { vec4 tex_colour = texture(u_Texture,v_tex_coord); colour = tex_colour; }; First Query:
      I have been following a tutorial on shaders and have replicated the code used in the tutorial. My program renders a square, onto which a texture (image) is placed. I have bound the vertex position coordinates to the first attribute index of the vertex array, and the texture coordinates to the second attribute index of the vertex array *1*.  The program works without any issues, but there are some aspects which have me confused and I therefore seek clarification from forum members.
      The vertex shader features the below lines:
      layout(location = 0) in vec4 position; layout(location = 1) in vec2 tex_coord;  From my understanding, these lines are essentially saying: "take the layout of attribute 0 and place it in the 'position' variable" and "take the layout of attribute 1 and place in the 'tex_coord' variable". This makes sense to me since the vertex shader determines the position of each vertex on the screen. However, in the fragment shader, I am more dubious:
      layout(location = 0) out vec4 colour; If the lines in the previous snippet are saying "take the layout of attribute x and place it in the 'y' variable", then what exactly is the above line saying? Specifically, why is the layout from the position attribute (attribute 0) being used and not the texture attribute (attribute 1)? 
      Second Query:
      I understand that the input variable in the fragment shader (v_tex_coord) is supplied by the output variable from the vertex shader (which originally gathered its data from the layout of attribute 1). But how is the final colour for each pixel here actually set? In the main() function of the fragment shader, the texture() function is used. From what I have gathered this function samples the colour of each pixel in the texture.
      Once a texture has been bound to a specific slot, we can set the uniform outside of the shader with glUniform() by returning the location of the uniform variable (location of "u_Texture" in this case) and then linking it to the previously bound slot. Presumably this is the step which links together the texture image and the uniform - meaning that 'u_Texture' now has access to the texture image via the slot to which it was bound (please correct me if I am wrong here).  The next assumption is that the texture() function will sample the corresponding colour value through its parameters ('u_Texture' - which now contains the texture image (or at least has access to the slot to which the texture image is bound) and 'v_tex_coord' which contains the coordinates to which the texture should be rendered). 
      Here is the part that confuses me most:
      The outcome of the texture() function is returned to the vec4 variable 'tex_colour' which then reassigns its value to the output vec4 variable 'colour'. What was the point in this last step? 'tex_colour' already contained the result of the texture() function so why does it then need to be reassigned to 'colour'? 'colour' is not predefined by OpenGL, I can change the name to 'the_colour', 'a_colour' or 'the_ice_cream_man' and the texture image is still rendered perfectly fine. Is it the case that the variable defined as the output in the fragment shader will be used to render the colour of each pixel regardless of its name? I suppose that the reason I ask this is because the 'gl_Position' variable in the vertex shader which sets the position appears to be a variable predefined by OpenGL whereas in the fragment shader this doesn't appear to be the case with the variable which sets the colour... some clarification of this would be greatly appreciated. 
      *1* - terminology may be wrong here but essentially I have used glVertexAttribPointer() to set the below vertices position coordinates to attribute 0 and the below texture position coordinates to attribute 1. The full program consists of 16 files and it didn't want to include source code for each file because most of it is irrelevant to the questions I am asking.
      float positions[] = { // vertices // texture -0.5F,-0.5F, 0.0F,0.0F, // x and y coordinates 0.5F,-0.5F, 1.0F,0.0F, 0.5F, 0.5F, 1.0F,1.0F, -0.5F, 0.5F, 0.0F,1.0F };  
    • By Brain
      This is my level editor workflow. Levels are represented by simple integers in the right hand column under a component called LevelInfo, and meshes are placed manually on the grid. The grid is replaced at runtime with actual gridactors.

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!