Next Code Drop?

#1 The AGDC Ustream yesterday had them saying it's 2 weeks or more till a real, public release. Here's hoping they don't run across any huge bugs :)

#2 Most likely this will be the 1.0 release (there'll not be beta 6).

#3 Awwwww .... I wanted one last round of complaint making .....

#4 Steve,
think of all the cool complainig when its released,
with known bugs....

#5 So let me get this straight. GG is going to release 1.0 that has things that still have not been been through a single round of beta testing?


sorry but I find that completely unprofessional.


so we get a 1.0 with beta untested features... Awesome. I hope we don't have to wait 6-9 months to get those fixed.

#6 The complainening has begun :P

I think Mich used the word "release candidate", actually. Hope they butt in on this thread once the AGDC is over with.

#7 See that is what I though. I was expecting a RC candidate any day but not a 1.0 Final or Gold or what ever you want to call it.

#8 I guess the plan is to bless the RC with 1.0 if nothing showstopping happened. I say take the time to fix everything users find, and make it the best 1.0 GG release ever.

#9 Amen

#10 Well with that said then I suggest everyone log any little bug that they find and hope that theres time for it to get addressed for a 1.0 release because to be question honest we are the first and last line of defence for allowing anything major to slip through.

Assume nothing is logged, report everything!

#11 Most of the last month has been spent bugfixing and polishing the features that are in Beta 5 and very few new features have been added (all minor). So, you guys pretty much did have your pass at testing a "release candidate" for 1.0. Beta 5 wasn't a release candidate in the "classic" sense because there were a fair amount of known issues but as far as features/improvements goes it was pretty close.

At this point, most of the team is ready to start working on the new features that will be in 1.1 (which should be a free upgrade and should have a pretty fast turn-around on it). If there turns out to be any critical/blocker bugs that make it past our month long QA cycle on 1.0 then we will get those addressed very quickly with a minor update asap (I honestly don't anticipate needing to do that).

I spent a fair chunk of this week walking through pretty much all of the features and tools of Torque 3D 1.0 with a bunch of high level executives and artists and was extremely happy with the stability and robustness (if your product is going to fail catastrophically it is going to be in front of high level decision makers...Murphy's law and all of that =).

#12 Jeez, I was only joking about the complaining ... but since I got your attention ... I've logged it! previously

#13

Quote:At this point, most of the team is ready to start working on the new features that will be in 1.1 (which should be a free upgrade and should have a pretty fast turn-around on it).

CUSTOM MATERIALS, CUSTOM MATERIALS!!!


BTW if a minor revision isn't a free upgrade... that would be bad for GG. Not having a way to apply shaders to geometry is a pretty big deal. Personally if everything 1.x isn't free just cut me a break and refund my money.

Also, I know my posts can be volatile and I'm reacting to what one person said in one post. I also know you have to eat, but not having a feature like that as part of what we have paid for already feels like misrepresentation.

A lot of what I'm saying here is based on unknowns... I just get nervous when someone says

Quote:should be a free upgrade

when they are talking about a feature I am primarily interested in (someone earlier said the custom material re-work is going into a 1.x release).

#14 I'm sure things will be fine. I can't see GG charging for a 1.x update in anycase. I mean.. it's not like their apple right?









;)

#15 Does it mean the documentation will magically appear soon? :D

#16 I seem to recall that was the focus now until T3D release - they pushed out the T2Di beta so we could break it while they polish T3D and docs. We'll hopefully get some clarification on Monday.

I've broken both T2Di and T3D (the former through scripts, the latter by just trying configuration options), but I am not sure if it's purely my fault yet ;)

#17

Quote:CUSTOM MATERIALS, CUSTOM MATERIALS!!!

I just did a simple test of a CustomMaterial and it appears to work fine (not accessible from the Material Editor of course).

#18 Actually, most things work on a custom material, but you are not able to receive shadows on it correctly, which makes using it pointless. I've seen it mentioned that the class is being taken out bit by bit, and the Material class will be expanded further instead, which makes sense. But right now, there's no way of creating a custom shader and receiving light on it without having to write a new material feature.

#19 @Matt, I'm just going off what I've tried and the contents of these threads below. If there's something I'm missing please let me know because I've been bouncing these around for a few betas now.

Here's how I came to my response above.

First

Quote:Its tricky because there is no way currently from a CustomMaterial to know what the exact vertex format will be for a particular material.

Second

Quote:In the trunk the sfxBackbuffer is completely removed so refraction as it was possible in TGEA using CustomMaterials is completely gone. We will try to address a better way for this to work in the future for 1.1 or 1.2

Third

Quote:
Only PostEffect supports $backBuffer as a texture input. CustomMaterial does support "$backbuff", but i'm not sure how well its working.

CustomMaterial frankly needs some improvements which i hope we'll be addressing in T3D 1.1. This is why PostEffect does not use CustomMaterial in any way.

Also the next release has some old refraction code removed which was not working properly with the latest engine changes. Refraction will be properly supported as a material setting in T3D 1.1.

#20

Quote:
Actually, most things work on a custom material, but you are not able to receive shadows on it correctly, which makes using it pointless. I've seen it mentioned that the class is being taken out bit by bit, and the Material class will be expanded further instead, which makes sense. But right now, there's no way of creating a custom shader and receiving light on it without having to write a new material feature.

I did a quick test with my basic CustomMaterial and was able to get it to receive lighting and shadows and cast shadows. This might not work with Beta 5 but does with with 1.0:


materials.cs

singleton ShaderData( BasicShader )
{
   DXVertexShaderFile 	= "shaders/common/basicV.hlsl";
   DXPixelShaderFile 	= "shaders/common/basicP.hlsl";
   
   pixVersion = 2.0;
};

singleton CustomMaterial( BasicCustomMat )
{
   mapTo = "building01walls";

   texture[0] = "#lightinfo";

   shader = BasicShader;

   version = 2.0;
};

basicV.hlsl

//-----------------------------------------------------------------------------
// Basic Shader
//-----------------------------------------------------------------------------

// Dependencies:
#define IN_HLSL
#include "shdrConsts.h"
#include "hlslStructs.h"

#include "shadergen:/autogenConditioners.h"

//-----------------------------------------------------------------------------
// Constants
//-----------------------------------------------------------------------------

struct VertData
{
   float3 position        : POSITION;
};

struct ConnectData
{
   float4 hpos            : POSITION;
   float4 screenspacePos  : TEXCOORD0;
};

//-----------------------------------------------------------------------------
// Main
//-----------------------------------------------------------------------------
ConnectData main( VertData IN, 
                  uniform float4x4 modelview : register(VC_WORLD_PROJ)
)
{
   ConnectData OUT;

   // Vert Position
   OUT.hpos = mul(modelview, float4(IN.position.xyz,1));
   
   // Deferred RT Lighting
   OUT.screenspacePos = OUT.hpos;
   
   return OUT;
}

basicP.hlsl

//-----------------------------------------------------------------------------
// Basic Shader
//-----------------------------------------------------------------------------

// Dependencies:
#include "shadergen:/autogenConditioners.h"

//-----------------------------------------------------------------------------
// Data
//-----------------------------------------------------------------------------
struct ConnectData
{
   float4 screenspacePos  : TEXCOORD0;
};


struct Fragout
{
   float4 col : COLOR0;
};

//-----------------------------------------------------------------------------
// Main
//-----------------------------------------------------------------------------
Fragout main( ConnectData IN,
              uniform float4    rtParams0       : register(C0),
              uniform sampler2D lightInfoBuffer : register(S0)
)
{
	Fragout OUT;
                       
   OUT.col = float4(1.0, 0.0, 0.0, 1.0);

   // Deferred RT Lighting
   float2 uvScene = IN.screenspacePos.xy / IN.screenspacePos.w;
   uvScene = ( uvScene + 1.0 ) / 2.0;
   uvScene.y = 1.0 - uvScene.y;
   uvScene = ( uvScene * rtParams0.zw ) + rtParams0.xy;
   float3 d_lightcolor;
   float d_NL_Att;
   float d_specular;
   lightinfoUncondition(tex2D(lightInfoBuffer, uvScene), d_lightcolor, d_NL_Att, d_specular);
   OUT.col *= float4(d_lightcolor, 1.0);

	return OUT;
}

Note: The S0 part of "uniform sampler2D lightInfoBuffer : register(S0)" and the trailing number of the "rtParams0" both need to match the texture unit number that you've bound "#lightinfo" to in the CustomMaterial. If, for example, you are using your diffuse map on texture[0] and #lightinfo on texture[1] then you will want lightInfoBuffer bound to S1 and to use the rtParams1 shader constant.