• подарки оптом, подарки опт
  • сувениры оптом, сувениры опт
  • бизнес сувениры
  • бизнес подарки
  • сувенирная продукция
  • купить футболки
  • бейсболки
  • ежедневники, ежедневник
  • подарки для женщин
  • подарки для мужчин
  • стеклянные двери
  • стеклянные перегородки
  • cтеклянные лестницы
  • изделия из нержавейки
  • My projects

    Amps – Basics

    During the past 4 weeks I implemented the framework for this particle system so Amps reached its first working version. In this article I’ll describe the basic workflow through a few examples.

    Before we move on I’d like to thank Attila Malarik who acted as 24/7 Unity and C# helpline despite crunching at his day job.

    Setting up the emitter

    I created an empty game object and added the Amps Emitter component. (All non functional parts of the Amps editor UI were removed for clarity.)

    The emitter stack contains a single module which controls the basic properties of the particle system, currently only the number of particles.

    After setting the spawn rate with a simple scalar module, I took care of the DeathCondition: if that stack produces a value of 1 for a particular particle then that particle gets killed. Having a constant value wasn’t very useful here so I set up a simple curve which outputs 1 when the ParticleTime reaches 3. This is the classic functionality of “kill by age” but the curve could be controlled by any of the emitter or particle properties, from emitter speed to particle alpha.

    The last step was adding a random Vector module to the position stack which defined where the particles were located. I turned on visualization to make it more apparent where the limits are.

    Simple motion

    Although the acceleration and velocity stacks are not yet implemented, there are several ways to make the particles move using only the position stack.

    When the weight of the vector module is decreased (indicated by the pie meter) the particles start to slide into place. This happens because the stack’s value is carried over from the previous update and not zeroed out. The less weight the module has the more time it’s going to take to fully overwrite the stack’s default value (0, 0, 0).

    In the second part of the video I set the blend mode to Add which made the the particles move beyond the point defined by the module: due to the blending mode their position “grows” steadily.

    Yet another way for movement is animating the X and Z coordinates of the particles by a curve: Here they steadily move sideways on X while their motion on Z reflects the drawn curve. Everything is driven by DeathCondition so the closer they get to fulfilling that condition the further they progress on the curves.

    The last example shows how to move particles using two modules: the first one provides the start value while the second “fades in” over time, using a curve in its Weight property.

    Samplers

    There is an important rule regarding random values in most modules: they are generated once and then stay the same throughout the life of the related entity (emitter of particle). If we want more control over this aspect we have to use the sampler group of nodes. The only sampler at this time is the Point Sampler module, so let’s see what can be done with it:

    It behaves very similarly to the Vector module: it defines a position in different ways. The important addition here is that it can roll the dice again when the sampling condition is met.

    First I set up the sampling so a new value was picked at every second and then, to make the transition apparent, I decreased the weight of the module to mix in particle position from the previous update. (As you might have already guessed, the flashing rectangles indicate when a new sample was picked for the highlighted example particle.)

    The second example shows how two samplers can be set up in a way that each samples when the other is in full effect thus avoiding any jitter caused by the sudden change in output values.

    So this is where the project is at: a lot is to be done but the foundations are working. If you have suggestions, ideas or questions, please contact me.

    Written on April 17th, 2013
    Categories: Amps, My projects

    Amps – Introduction

    I teamed up with my friend and veteran Unity user Attila Malarik to make a particle system for Unity: It’s called Another Modular Particle System or “Amps”.

    Attila handles the lower level tasks (framework, resource management, etc), I cover high level system design and UX and when it comes to the middle layer (creating the reusable building blocks) we will share the work as we go.

    The user interface

    I’ve just finished the first iteration of the editor window. The controls are not linked to anything yet but the layout reflects the base idea behind Amps:

    http://www.zspline.net/blog/wp-content/gallery/amps/amps01.png

    A particle emitter itself is a component on a GameObject. (So a particle system contains exactly one emitter so I’ll use those terms interchangeably.) The emitter has several stacks defining it’s behavior as seen on the left most column. Each stack can contain any number of modules and each module has several properties. While simpler property types can be edited right in the property list more complex ones get dedicated value pickers.

    Now let’s see each part a bit closer.

    Stacks

    The Emitter stack is a special one as it contains exactly one module for setting up the particle system. Particle limits, LOD configuration, update rate and similar properties belong here.

    The Rendering stack can contain one or more rendering modules which define how the abstract particle data is displayed. Point, arrow, sprite, ribbon and mesh modules are typical examples but it should be possible to extend the system beyond that including skeletal meshes for a very crude crowd simulation.

    External Influences is about entities outside the particle system which affect it’s properties. For instance colliders directly change particle position, wind zones affect acceleration, color volumes adjust particle color.

    The Spawn Condition stack defines when to spawn particles. If any of the modules in there return ‘true’ then a spawn cycle is initiated. Such a cycle lasts as long as the result of the Spawn Duration stack and will produce as many particles as indicated in Spawn Amount.

    The next stack group deals with particle removal in a similar fashion: when to kill one and how long it will take for them to die.

    The yellow stacks represent the standard set of particle attributes.

    Typical usage scenarios for each stacks will be covered in separate articles so now let’s move on to the second column, the modules list.

    Modules

    Data flows downward between modules: the result of the first one is modified by the second one and so on like an upside down Photoshop layer stack. Also somewhat similar to PS is that modules generally have Weight and Blending mode properties which define how they change the result arriving from above them. Certain types of modules (like math operations) don’t have blending modes only weight. Another permanent property is the Description field where the user can take notes regarding the function of the module. It is a very important feature which keeps even complex particle systems easy to read.

    The properties feed the internal mechanics of the module which – combined with the result of earlier ones – produce a single value to be passed on. Internally modules are treated as black boxes: they take a standard set of input parameters, create their own UI representation and eventually produce a vector4. This way third parties will be able to extend the system simply by following a few design rules.

    Modules can be added, disabled, duplicated, instanced, rearranged, and deleted in this list view. Their properties are edited in the property list.

    Properties

    A module can contain any number of properties. They are grouped into logical units and frequently used properties are displayed at the top for easier access.

    There are several property types: bool, integer (dropdown menus), string, scalar, vector4 and color. (The last one is really just a vector4 represented differently to the user.)
    Scalars, vectors and colors can have a constant value, a random constant, a curve or a random curve. These more complex definitions have their dedicated value pickers in the right most column.

    Value pickers

    Here are the currently functional value pickers:

    Random scalar

    Scalar curve

    Random scalar curve

    Vector

    Random vector

    Color

    The color picker is a replacement of the inbuilt one which doesn’t support high dynamic range values. (The three part color preview strip shows the clamped color, the tonemapped one and the visual alpha.)
    I’ll also have to create our own curve editor because the default is rather limited: unable to display multiple curves at once, presets can’t be changed, there is no numeric input for the selected key.

    And that concludes this introduction to Amps. If you have any questions or suggestions please don’t hesitate to contact me.

    Written on March 11th, 2013
    Categories: Amps, My projects, Unity

    Update

    In the new year I started actively looking for a job abroad so I created a portfolio magazine and updated the article about the now defunct Punisher PSN game with two videos showing the maps and special effects I worked on.

    Currently I’m developing a simple but visual effects heavy Unity game called One Minute Dungeon. It’s really just a real life scenario to learn the ropes and to test what the engine can do vfx wise.

    It became clear early on that the stock particle system is very limited, especially when compared to UDK’s Cascade. Right now I don’t mind this because the tricks and workarounds I have to come up with force me to learn more about the internal workings of the engine. However in an actual production environment I’d be very unhappy with the sub-par solution so with a friend of mine we started working on a flexible, modular particle system (AMPS). The high level design is in reasonably good shape so when I’m done with the UI mockups then I’ll be able to write a post about the general idea.

    Written on February 24th, 2013
    Categories: Amps, One Minute Dungeon, Unity

    Updates

    Layer exporter for modo is updated, now it should work fine with 601.

    I also updated my Photoshop panels to CS6.

    Finally the Dynamic Grid editor extension for Unity had a patch fixing some issues and adding some functionality.

    Written on December 4th, 2012
    Categories: My projects

    Texture Synth filter for FilterForge

    Recently I finished a filter which takes a low resolution, non-tiling image like this:

    and creates a higher resolution, seamlessly tiling version:

    You can find the filter here and the documentation here.

    Written on October 17th, 2012
    Categories: Filter Forge filters, My projects
    Tags:

    Unity web player embedding

    This is a test for inserting the Unity web player to blog posts:

    If all went well you should be able to the view with LMB drag and zoom with the mouse wheel or RMB drag.

    The scene uses my latest project, a model viewer plugin for the Unity editor.

    UPDATE: The plugin is now available in the asset store.

    Written on October 4th, 2012
    Categories: My projects
    Tags:

    Unity3d first impressions

    I’m taking a break from the Unreal Engine to spend some time with Unity3d. I started working on a realtime model viewer for this blog but got sidetracked and made a dynamic grid editor extension first, available in the asset store.

    I yet to mess with the game engine part of Unity but the editor itself is excellent. I’ve been using UnrealEd for 13 years so it’s pretty much muscle memory by now but when compared to Unity, it just doesn’t hold up. The Unreal Engine still has one of the best node based material editor in the industry, something Unity sorely lacks, but otherwise it’s not even contest.

    My favorite editor features so far:

    • Editor scripting: From creating game objects to drawing custom gizmos in the viewport, great many things can be coded.
    • Flexible editor GUI: dockable panels, layout presets.
    • Asset management: Like directly importing modo files… mind -peww- blown.
    • On the fly C# compile: Code in Visual Studio, switch back to Unity, wait for compiling to finish, see results.

    So I’m very excited to explore this new toy further.

    Written on September 1st, 2012
    Categories: My projects
    Tags:

    Mallet Pinball: Behind the scenes

    About a year ago I wrote an article about the early days of the pinball table, now after several mothballed months it’s done and here is how it works.

    The basic control setup

    A GVMachineController actor is on the map and a kismet node makes sure that the player takes control of it when the level loads. After that, all input is processed by the machine which then adjusts linked actors (changes position, rotation, etc). For example here is how the right flippers are set up:

    Read the rest of this entry »

    Written on August 8th, 2012
    Categories: Gavit, My projects, UDK
    Tags:

    Mallet Pinball

    This pinball-air hockey mashup was the very first prototype I created using Gavit. I worked on it every now and then, pimped the effects, tested Gavit’s new features and so on, until it was worth of a video:

     

    The technical details are discussed in this “behind the scenes” article.

    Written on August 1st, 2012
    Categories: Gavit, My projects, UDK
    Tags:

    Guided rigid bodies

    I previously discussed replaying user input and in this article I’ll cover a related feature: recording and replaying rigid body motion.

    The basics are quite simple: dump transformations of a physics driven actor to a file and then convert that data into a matinee, like before. However simply replaying the motion track with a mover has an inherent problem: impact and slide effects, defined in physical materials, won’t happen because no actual collisions occur. All the special effects (impact dust puff, damage decals, sparks, etc) would need to be placed and timed manually. That would be a bad workflow.

    Fortunately the solution is rather straightforward: let’s constrain a KActor to a mover: the mover replays the given motion data while tries to keep the physics driven actor on the same path. The guidance is gentle since it doesn’t work against the physics engine, only corrects small inconsistencies so the result is the same every time.

    In the following video I actually used an invisible mover to replay matinee data and placed a constraint on the map to link it to the KActor but later on that won’t be necessary: our own physics driven actor (GVKActor) will spawn its own constraint and in there will adjust the LinearPositionDrive and AngularPositionDrive settings.

    Anyway here is the proof of concept map:

    However there is something wrong: on hitting the wall the balls sometimes don’t produce the dust puff impact effect. The source of the problem is the fixed rate motion data was sampled: although transformations were recorded 60 times a second, roughly half of the collisions still happened between measurements.

     http://www.zspline.net/blog/wp-content/gallery/gavit/PhysicsRecordingProblem01.png

    The dashed line indicates the original path of an object while the orange curve is the matinee data reconstructed from the samples. The collision happened while we were not looking so we’re left with a flat part keeping the object away from the surface it originally hit.

    I came up with two ideas I yet to implement. The first one is pretty obvious: let the physics actor report its status every time its RigidBodyCollision event occurs. However past experiences show that it’s not a 100% reliable, I’ll have to see if it’s good enough.

    The second potential solution is trying to guess the time and place of the collision based on the data we have.

    http://www.zspline.net/blog/wp-content/gallery/gavit/PhysicsRecordingProblem02.png

    First we generate velocity vectors from the samples then we scan for a potential collision: we know that physics driven actors generally move in a smooth, gradual fashion so the difference between two samples will be small unless a collision happened. For example A and B vectors are kinda different but not much. After comparing B to C/D we can be pretty sure that a collision happened there.

    The next step is extrapolating two new velocity vectors, and extension of B and D in the example, and finding their intersection (or mid-point where they are closest to each other). That point is our guess which might not be exactly precise but a lot better than what we had before.

    I’ll implement these solutions after I’m done with one of the earliest, yet still unfinished prototypes I have in the pipeline. Stay tuned.

    Written on July 26th, 2012
    Categories: Gavit, My projects, UDK
    Tags: