Nice. Keep going!......
Better not. If anything, get the physical model right and try to optimize the... I think I should probably get a more powerful PC. My mac mini cried when I turned up the resolution
I've got the final equation implemented! And hell, everthing works pretty,
pretty good, and pretty, pretty smooth!Gifs incoming...
Hehe, thx! Coming up...Congrats, looking forward to seeing
To circumvent this issue I do let my phantasy go and imagine how it would
After optimizing, have you thought about selling the whole lighting package on the Unity Asset Store? Might get you some nice cashflow. = DCongrats, looking forward to seeing
You're very right...I would be tempted to gallop off into unrelated niceties with a more powerful machine rather than focusing on core issues. I have to stop myself from prematurely optimising too. I will definitely get a showcase rig before the game releases though, but at the moment having such a relatively modest machine does encourage some discipline.
I love your very meticulous work
Ah!! Sorry if I put you to any trouble. Basically the blue tint was due to bad compression of the flux in the RSM. In Dachsbacher's implementation, he compresses the flux into a 8 bit float in order to save a vertex texture fetch in the splat shader. I was using a 16-bit render target for the RSM, so his compression wasn't suitable.
I initially solved that by just rendering the flux out to a separate render target, as a full vector, uncompressed.
However I've figured out how to compress it into a 16-bit value to save using that extra render target... but tbh I don't notice much performance difference. And under some occasional circumstances a subtle bit of 'blue' still appears in the white flux. So I might switch back.
Looks sweet, man. Keep up the good work!I've done some work on the character art for the character driven first act of the game, but there's much left to do. I plan to do a ton of custom environment work for this portion.
But here's kinda the idea. Here you can see Charley, Rook, and Pasha (Pasha is riding on Rook's back right now).
The character sprite on the let looks neat, and so did the witch since I didn't mention it!I've done some work on the character art for the character driven first act of the game, but there's much left to do. I plan to do a ton of custom environment work for this portion.
But here's kinda the idea. Here you can see Charley, Rook, and Pasha (Pasha is riding on Rook's back right now).
Love the 'sense of depth' in your artwork. Stellar work!Some things done today.
Enabled a smooth falloff of indirect light. This localises the bounced light a little more but I think it's more physically correct.
Added some vanilla shadowing. Very basic but helps in debugging, helps explain why a surface may not be receiving an indirect bounce that you might think should be.
Also messed with wall colours and higher resolutions just for fun. I think I should probably get a more powerful PC. My mac mini cried when I turned up the resolution
http://i.imgur.com/yT7XVd6.png[/IG]
[IMG]http://i.imgur.com/RRvsqOm.png[/IG]
I really want to implement a non-circular 'box' spot light, which would be a lot more correct for this right now, but for some reason that's turning out to be less trivial than I thought.[/QUOTE]
The idea this is realtime is quite mind-boggling to me. It usually takes minutes to render something that good with 3D rendering software!
[quote="Jobbs, post: 70891331"]I've done some work on the character art for the character driven first act of the game, but there's much left to do. I plan to do a ton of custom environment work for this portion.
But here's kinda the idea. Here you can see Charley, Rook, and Pasha (Pasha is riding on Rook's back right now).
[img]http://www.ghostsonggame.com/screens/rookcharleyss2.png
They were from a 720p run, I just wanted to see how it looked at a higher res. But 640x480 is more reasonably realtime on this machine...been working on my witch...
I kinda wanted her to force throw the various rocks from the air at you, like vader, it's making me have some headaches in terms of getting it right.. I'll come back to this later.
) And LPV is one I should do. Though scalability will be pretty important for my game (in terms of light multiplicity and geometry complexity). And wherever possible within this pipeline I'll let people toggle improvements on or off, and dial other things up and down. Like ISMs for example, if I do use them, could be an on/off thing.Will have to look into parabolic maps. Thanks.
I would ideally like to implement and compare as many approaches as possible
In my game I plan to have a standard unity pipeline, and then this one, which I'll probably label as Experimental. So for me, it'll be open season. I kind of hope my game can be a long term project that can keep evolving to keep up with the best in realtime tech - or the best that I can make. That would be an ideal goal for me, I'd love to be in that position. And I don't mind so much pushing into 'barely viable' territory...I think one of the nice things about an indie game is you can really go balls out if you want and really give high end PCs something to munch on. I sort of miss the days when PC-exclusive devs did things that kind of forced me to dial my resolution down to 640x480
Anyway, many miles to go...
. In that case ISM or LPV would be the next logical step. Any thoughts about Voxel Conetracing in the far future? anyways keep the up the good work. As soon as I got some more free time I'm gonna post some of the stuff ive been working on aswell.I've done some work on the character art for the character driven first act of the game, but there's much left to do. I plan to do a ton of custom environment work for this portion.
But here's kinda the idea. Here you can see Charley, Rook, and Pasha (Pasha is riding on Rook's back right now).
It might be that Jobbs is an artist or has an art background, rather than a programming one. A lot of indie game developers may be the opposite.
If you have more than one person, artist + programmer can probably work pretty well though.
It might be that Jobbs is an artist or has an art background, rather than a programming one. A lot of indie game developers may be the opposite.
Things like Stencyl, Construct 2, and Game Maker are making it more possible for the people without as much developer experience to make their own games. I almost feel like it is more difficult to become a good artist than to learn development tools, but I went after software engineering as a career, so art tends to be magical to me.
3 ... 2 ... 1 ... BOOM!
That's it! Six weeks of hard work.
A 6-DOF fully non-linear rigid body simulator including variable mass written
in plain C. All equations were derived from scratch. The code is pretty small
and works on just plain data-structures and has no external dependencies
making future integration into any framework as plain as day.
The rocket (dimmed yellow line) consist of two stages with their centers
indicated by a yellow dot, respectively. The lower stage, the one closer the
bottom, carries double the weight as the upper stage. Hence, the center of
mass (white dot) is more towards the lower stage, initially. About 90% of the
lower stage is propellant fuel getting burned at a given rate once the rocket
lifts off from the ground at full thrust. At the tail end of the lower stage
there is a nozzle indicated with a dimmed white line showing the amount of
propellant fuel (white: full, black: empty).
I imagine it's pretty fun to tinker with. And wings could make for some really awesome dynamics.3 ... 2 ... 1 ... BOOM!
That's it! Six weeks of hard work.
A 6-DOF fully non-linear rigid body simulator including variable mass written
in plain C. All equations were derived from scratch. The code is pretty small
and works on just plain data-structures and has no external dependencies
making future integration into any framework as plain as day.
The rocket (dimmed yellow line) consist of two stages with their centers
indicated by a yellow dot, respectively. The lower stage, the one closer the
bottom, carries double the weight as the upper stage. Hence, the center of
mass (white dot) is more towards the lower stage, initially. About 90% of the
lower stage is propellant fuel getting burned at a given rate once the rocket
lifts off from the ground at full thrust. At the tail end of the lower stage
there is a nozzle indicated with a dimmed white line showing the amount of
propellant fuel (white: full, black: empty).
The rocket starts with a given angular velocity at lift-off time. The nozzle
is held down such that all the thrust is generated in the upward direction
lifting the rocket off from the ground. During this time the thruster embedded
within the lower stage produces thrust by burning fuel at a given rate pushing
it through the nozzle. This consumption of propellant will reduce the mass of
the lower stage and will also reduces the weight of the rocket and as such
increase its acceleration even more. And due to the loss in mass of the lower
stage, the center of mass will shift towards the upper stage of the rocket.
A few seconds after lift-off, but before burnout, the nozzle suddenly tilts
out producing a disaster. In tilt position the nozzle produces a moment/torque
on the lower stage of the rocket until burnout. Since the thruster is still
burning at full thrust, the center of mass keeps moves right to the center of
the upper stage. During this time the center of mass, which also equals the
center of rotation of the rocket, moves father and father away from the
nozzle. The generated angular momentum coupled with the change in inertia of
the lower stage due to propellant burning, and due to the increase in distance
of the lower stage to the center of mass, will lead the rocket to tune over.
This becomes only possible this way by carefully considering the non-linear
gyroscopic term (wxIw) within the angular momentum equation, which is fully
implemented here, and, in addition, by including the time rate of change of
the inertia tensor -- which, according to my knowledge, is something new for
video games, not even speaking about variable mass / center of mass.
The feature of having a rate of change of mass that influences the whole
system can even be useful for games outside of any realism. For, one can
consider the rate of change of mass as a parameter. You may specify a constant
rate or make this rate a function all by itself. Since the rate of change of
mass influences the mass distribution, and as such the motion of the object
under consideration, one may produce quite interesting motion patterns. That
is to say, one may build some mass-rate function that will, as an effect,
shift the center of mass from one point to another and as such influences the
motion of the object. Can be pretty cool, something to experiment with.
Next-up:
(a) Runge-Kutta of order 4 for all equations
(b) Wings / Airfoils
Still, like he said, it's pretty damn impressive given it's just you. Do you have a bunch of prior experience doing pixel art? Just lots of practice?Thanks.
I think the way in which 3D graphics is "easier" has more to do with the flexibility it provides. It's easy to change the appearance of the characters, what they're holding, wearing, whatever, since it's all real time. 2D art has its own appeal but is difficult to have the same freedom and flexibility with.
I don't know that it's particularly hard to make a 2D game. Wayforward is a relatively small development studio and they make really top notch 2D games. I think the reluctance for most studios to go 2D is because making a 2D game imposes some limitations and developers find this unappealing.
Oh cool! Thanks for the insight and the descriptions of some approaches you've used. I've thought about going the tablet route, but I tried one way back when and it just never clicked; I couldn't get a handle on looking at a screen while "drawing" on the tablet. I'm sure I could probably get it with practice, the traditional route just seems like a better way for me to experiment. I know it adds work with having to ink lines and do clean-up after scanning them, it just seems like a better entry point. It's been many years -- probably 15+ -- since I was drawing regularly. I gotta brush up first.
It is indeed a hindrance to readability, especially to people on smartphones or with browser windows of different sizes. If I recall correctly when I asked, it's out of habit and personal belief because they like using Unix-esque text-formatting system (Tex or Vim?)...but it's also weird to me because I feel like I've checked the lines before and they don't always word-break at 80 characters. So maybe they are hand-edited too.
Oh, cool, a fellow Austin-ite! Do you have any recommendations of how to get involved with the game dev community here? I'm fairly new to the city.
I would think Construct, actually, but I'm not too well versed in it. Anyone else with a recommendation?
Shader "Custom/Matte Shadow" {
Properties {
_Color ("Main Color", Color) = (1,1,1,1)
_MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
_Cutoff ("Alpha cutoff", Range(0,1)) = 0.5
}
SubShader {
Tags {"Queue"="AlphaTest" "RenderType"="TransparentCutout"}
LOD 200
Blend Zero SrcColor
Offset 0, -1
CGPROGRAM
#pragma surface surf ShadowOnly alphatest:_Cutoff fullforwardshadows
fixed4 _Color;
struct Input {
float2 uv_MainTex;
};
inline fixed4 LightingShadowOnly (SurfaceOutput s, fixed3 lightDir, fixed atten) {
fixed4 c;
c.rgb = s.Albedo*atten;
c.a = s.Alpha;
return c;
}
void surf (Input IN, inout SurfaceOutput o) {
fixed4 c = _Color;
o.Albedo = c.rgb;
o.Alpha = 1.0f;
}
ENDCG
}
Fallback "Transparent/Cutout/VertexLit"
}