Jump to content

LukasPJ

WEBGRU
 View Profile  See their activity

  • Posts

    462

  • Joined

  • Last visited

 Content Type 

Posts posted by LukasPJ

    State of the GG forum.

    in General

    Posted

    Hey guys

    ,


    So apparently, GG has chosen to keep their forums alive anyways and has begun trying to fixing the spam issues. That's about the only thing they'll fix though :).


    There is a little bit of info here. Ofc, this is gonna be a slight issue because of confusion of new users and search engine conflicts.


    This has been discussed vividly on IRC, but I thought it would be smart to have a persistent discussion here.


    Some people think it's a little odd that GG react to the communties issues exactly a week after the community decided to try and solve the issues themselves. Others think that this might be something that could lead to the return of the community back to the old forum.


    Personally, I don't care one bit... I'm just annoyed that this means that we can't have one single forum for T3D and must live with that old shadow disturbing our community.

    Tweening

    in Gameplay

    Posted

    Tweening? What the hell is tweening!?

    There some old TorqueScript for moving stuff around in the old library.cs file that I remember using once.

     

    This can do more than just move stuff around! (Also library.cs? What file is that? :P)


    For example you could change its scale so it would get wider over time :P Or rotate it in weird ways. It's basically a C++ version of Twillex

    Multithreading the engine

    in C++

    Posted

    Slightly off topic but one of the biggest things i have seen that is really holding T3D back, is just how CPU bound it is. Using T3D now on a decent size level it quickly becomes very apparent how under utilized the GPU is. It needs multi threading.

     

    I think Timmy is write, and I just wanted to start a discussion on which part of the engine it'd make sense to multithread.

    The ParticleSystem is one, which I can probably handle in a meaningful way :)


    Any other ideas?

    PBR: Principles, Practice, and Prepwork

    in Rendering

    Posted

    Wait, so there's already a PBR build?

    v0245xP_HVk


    The numbers look fine, there's a lot of odd things about the deferred shading compared to lighting. Like all the rendered terrain cells are override cells, and there is in general a higher polycount (although fewer drawcalls?) :P Also the level doesn't look like it's exactly the same :P

    Tweening

    in Gameplay

    Posted

    Hey guys, I wrote a Tweening class for Torque3D that can be found here.


    It's pretty simple to use:

    %tween = new Tween(){
   Duration = 5; // This is in seconds.
   Target = SimpleWall; // Any SimObject.
   ValueName = "x"; // Syntactic sugar for the x-coordinate.
   ValueTarget = "5"; // The destination value, this is the absolute value. No relative supported atm.
   EaseDirection = $Ease::Out; // This is just the stock easing values.
   EaseType = $Ease::Circular; // Again, this is a stock thing, I didn't implement the $Ease enum.
};
 
%tween.play();

     

    There is syntactic sugar for:

    Position (x, y, z).

    Rotation(rx, ry, rz).

    Scale(sx, sy, sz).


    But any numerical field that is accessible through TorqueScript can be used. (Includes globals).


    The Tween class has the following methods:

    • Play - Starts the tween
    • Pause - Pauses the tween
    • Rewind - Rewinds the tween back to the beginning (does not stop it currently)
    • Reverse - Plays the tween in reverse

     

    And an "onFinished" callback.


    The code is not completely finished, but it's fun to play with!

    5Yr4O1NU_II

    ParticleSystemRefactor backwards compatibility

    in TorqueScript

    Posted

    Hey guys, as you may know I'm refactoring the particle system and it's being completely changed. This is how it works in script now:

    datablock SphereEmitterData(DefaultParticleEmitter)
{
};
 
datablock BillboardRendererData(DefaultParticleRenderer)
{
   textureName = "core/art/defaultParticle";
};
 
datablock StickyBehaviour(StickyBHV) 
{
};
 
datablock ParticleSystemData(DefaultParticleSystem)
{
   Emitter = DefaultParticleEmitter;
   Renderer = DefaultParticleRenderer;
   ParticleBehaviour[0] = StickyBHV;
};
 
datablock ParticleSystemNodeData(DefaultNode)
{
   timeMultiple = 1.0;
};

     

    This provides ALOT of flexibility, the old system really only supported spherical emitters. This way you can have various different emitter types and mix and match emitters and renderers.


    However as you may have guessed this also breaks compatibility with:

    2. The ParticleEditor
    4. Current scripts

     

    Now, I don't see the ParticleEditor as that big of a loss, because most of what you can do through that, you can do through the DatablockEditor as well.. That said, I might write a new one. But the scripting compatibility is an issue. Now if this was released in version 4.0, it would be 'okay' to break compatibility, as that's what major versions are for.


    But does the community think that we should maintain backwards compatibility? It'll be a MAJOR hassle and gonna take a while to figure it out, and imo the only result is that you have to spend a couple of hours rewriting your old datablocks. What do you say? Am I allowed to break backwards compatibility, or is it really that vital?


    Refactor can be found here

    [Done] Nomination of new supah-admin

    in Website Feedback

    Posted

    We need to share the power, so the whole fate of the forums doesn't lie in my hands. (Not that I'm going anywhere, just for security.. It's just a precaution)


    Therefore we need a new:

    http://i.imgur.com/W35FCx0.jpg


    In IRC @TRON was nominated. Does anyone else wanna step up or will it be a peace-election?


    You got 'till 18-02-2015 12:00 GMT.


    If you haven't found this thread by then, then

    http://cdn.meme.am/instances/500x/57569901.jpg


    Nomination starts.... NOW!

×
×
  • Create New...