Let's say I want to replicate Planeshifting from Legacy of Kain: Soul Reaver in Unity.
There are 2 realms: Spectral realm and Material realm.
The Spectral realm is based on the Material realm, only has the geometry distorted and certain objects fade out/become non-interactive.
In Soul Reaver, it is used as means to go to areas where you normally wouldn't be able to in Material (distorting geometry), to use other powers (such as going through grates).
My question is: Is it even possible at all to implement this in Unity 3D? (I would need the Scene(level) or the objects to have 2 states somehow that I could switch beetween/distort to real-time.)
I would call this a rather advanced topic and there are multiple ways of accomplishing a at least similar effect.
But to answer your actual question straight away - Yes it is possible.
And here are some approaches i would take (i guess that would be your next question ;))
The easiest way is obviously having game object which have their collider and renderer disabled (or the whole object) when "changing
realms". But this for sure isn't the best-looking way of doing it,
even tho a lot of motion blur or other image effect could help.
(Depending on what shaders you use, animating the alpha value can
create a fading effect as well)
The more advanced way would be the actual manipulation of vertices (changing the object). There are quite a few tutorials on
how to change the geometry of object. Take a look at Mesh() in the
official documentation:
http://docs.unity3d.com/ScriptReference/Mesh.html
A class that allows creating or modifying meshes from scripts.
Another way (didn't try) thats rather easy would be using shape keys. I don't know which Software you use to create your
world/models but blender has this function which allows you to define
a base shape, then edit the verticies in blender and save it as a
second (or more) shapes. Unity can blend smoothly between those
shapes as being shown in this video:
https://www.youtube.com/watch?v=6vvNV1VeXhk
Yes it will be possible in Unity3D, but your question is quite general. You could try something like having 2 models per GameObject (perhaps as children or fields on the script) and disabling 1 of them depending on which realm the player is in. You could have 2 scenes for each level and switch between them, though that might be too slow. You could see if there are any plugins/assets that allow you to define 2 models and morph between them. There are probably a number of other routes you could take, but I can't really help more until you've chosen a path.
Related
I have a specific way of generating meshes and structuring my scene that makes occlusion culling very straight forward and optimal. Now all I need is to know how to actually show or hide a mesh efficiently using the ECS hybrid renderer. I considered changing the layer to a hidden layer in the RenderMesh component but the RenderMesh component is an ISharedComponentData and so does not support jobification or burst. I saw the Unity BatchRendererGroup API and it looked promising with its OnPerformCulling callback but I don't know if it is possible to hook into the HybridRenderSystem's internal BatchRenderGroup. I also saw the DisableRendering IComponentData tag that I guess disables an entities rendering. However, again, this can only be done from the main thread. I can write my own solution to render meshes using Graphics.DrawMesh or something like it, but I would prefer to integrate it natively with HybridRenderer in order to also cull meshes that are not related to my procedural meshes.
Is any of this possible? What is the intended use?
I'm not sure it's the best option but you can maybe try parallel command buffer:
var ecb = new EntityCommandBuffer( Allocator.TempJob );
var cmd = ecb.AsParallelWriter();
/* job 1 executes with burst & cmd adds/removes Disabled or DisableRendering tags */
// (main thread) job 2 executes produced commands:
Job
.WithName("playback_commands")
.WithCode( () =>
{
ecb.Playback( EntityManager );
ecb.Dispose();
}
).WithoutBurst().Run();
There is another way of hiding/showing entities. But it requires you to group adjacent entities in chunks spatially (you're probably doing that already). Then you will be occluding not specific entities one by one but entire chunks of them (sectors of space). It's possible thanks to fabulous powers of:
chunk component data
var queryEnabled = EntityManager.CreateEntityQuery(
ComponentType.ReadOnly<RenderMesh>()
, ComponentType.Exclude<Disabled>()
);
queryEnabled.SetSharedComponentFilter( new SharedSector {
Value = new int3{ x=4 , y=1 , z=7 }
} );
EntityManager.AddChunkComponentData( queryEnabled , default(Disabled) );
// EntityManager.RemoveChunkComponentData<Disabled>( queryDisabled );
public struct SharedSector : ISharedComponentData
{
public int3 Value;
}
The answer is that you can't and you shouldn't! Unity Hybrid rendering gets its speed by laying out data in sequence. If there was a boolean for each mesh that allowed you to show or hide the mesh Unity would still have to evaluate it which I guess is not in the their design philosophy. This whole design philosophy in general did not work out for me as I found out.
My world is made up of chunks of procedurally generated terrain meshes (think minecraft but better ;)) The problem with this is that each chunk has its own RenderMesh with a unique mesh... meaning that each chunk gets its own... chunk... in memory xD. Which, as appropriate as that sounds, is extremely inefficient. I decided to abandon Hybrid ECS all together and use good old game objects. With this change alone I saw a performance boost of 4x (going from 200 to 800fps). I just used the MeshRenderer.enabled property in order to efficiently enable and disable rendering. To jobify this I simply stored an array of the mesh bounds and a boolean for if it is visibile or not. This array I could then evaluate in a job and spit back out an index list of all the chunks that needed their visibility changed. This leaves only setting a few boolean values for the main thread which is not very expensive at all... It is not the ECS friendly solution I was looking for but from the looks of it, ECS was not exactly my friend here. Having unique meshes for each section of my world was clearly not the intended use case of Hybrid ECS.
I am an inexperienced programmer, I am looking for advice on a new unity project:
I need to generate terrain for a 3d game from fairly large tiles. For now I only need one type of tile, but I was thinking, I better set up a registry system now and dynamically generate that default tile in an infinite grid. I have a few concerns though, like will the objects continue to load as the character moves into the render distance of a new tile (or chunk if you rather). Also, all the tutorials I have found are wrong for me in some way, like it only works in 2d and doesn't have collision, or is just a static registry and does not allow for changing the content of the tiles in-game.
Right now I don't even know what the code looks like to place a 3d object in the scene without building them from vectors, which maybe I could do. I also don't know how I would want to trigger the code.
Could someone give me an idea of what the code would look like / terminology to look up / a tutorial that gives me what I need?
This looks like a pretty big scope for a new programmer but lets give it a shot. Generating terrain will be a large learning experience when it comes to performance and optimization when you don't know what you're doing.
First off, you'll probably want to make a script that acts as a controller for generating your objects and put this inside of the player. I would start by only making a small area, or one chunk, generate and then move on to making multiple chunks generate when you understand what you're doing. To 'place' an object in your scene you will want to make an instance of the object. I'd start by trying to make your grid of objects, this can be done pretty easily on initialization (Start() function) through a for loop, for testing purposes. IE, if you are trying to make 16x16 squares like minecraft; have a for loop that runs 16 times (For the x) and a for loop inside of that to run 16 times (for the z). That way you can make a complete square of, in this case, cubes. Here is some very untested code just to give you an example of what I'm talking about.
public GameObject cube; //Cube you want to make a copy of, this will appear in the editor
void Start(){
for(var x=0; x < 16; x++){
for(var z=0; z < 16; z++){
GameObject newCube = Instantiate(cube); //Creates an instance of the 'cube' object, think of this like a copy.
newCube.transform.position = new Vector3(x, 0, z); //Places the cube on the x and z which is updated in the for loops
}
}
}
Now where you go from here will be very different depending on what you're trying to do exactly but you can start by looking into perlin noise to add in a randomized y level that looks good. It's very easy to use once you grasp the general concept and this example I provided should help you understand how to use it. They even give good examples of how to use this on the Unity docs.
In all, programming is all about learning. You'll have to learn how to only take the parts of resources that you need for what you're trying to create. I think what I provided you should give you a good start on what you want to create but it will take a deeper understanding to carry things out on your own. Just test different things and truly try and understand how they work and you'll be able to implement parts of them into your own project.
I hope this helps, good luck!
I'm working on a 2D platformer in c#, as most people are, but I have got a decent start to the project I have a class called Player, I then handle all collision for that player as well as the scrolling of the blocks in the background within the gamescreen class. I have just added another player (as a different class in this case a warrior), but all of my collision is based around the players positions and velocity, how would I change the blocks movement and collision to be around the warrior's velocity and positions instead (without duplicating or creating quite a lot of code).
Thanks for any help Sam.
Inheritance is your friend. You should probably have a base Player class, or even something more low level than that. The base class implements the colision detection and movement code. Your Warrior and other player types should inherit that class and override different parts to change the behavior.
My strategy works approximately like this:
I have a Character class. It contains a HitboxSet. The HitboxSet exposes an active Hitbox. All my collision is done based on Hitbox instances. Depending on what kind of character I need, I pass in different sprites, hitboxes, movements, etc.
The result is a high degree of flexibility, while allowing you to keep your concerns thoroughly separated. This strategy is known as Composition, and is widely considered superior to inheritance based strategies in almost all cases.
The main advantage of this strategy over inheritance is the ability to mix and match components. If, one day, you decide that you need a new projectile that's smaller than a previous one, and moves in a sine pattern, you simply use a new sine movement. You can reuse such things infinitely, in any combination.
You can do something like this with inheritance: a child class can override a method and do something differently. The problem is that you either keep adding new child classes with different combinations and end up with a terrifyingly complex tree, or you limit your options.
In short, if something is naturally going to vary, as it almost certainly will in a game, those variations should be distinct classes that can be combined in different ways rather than mutually exclusive overrides.
I am making project for school "simulation of intersection" and i need few advices.
Canvas is a parent.
For now i have created class "Car" which contains some properties like Rectangle(body), Speed, Enums (Car type, Direction of moving etc.). So:
What is a best way to move objects in wpf? (I think about DispatcherTimer, but here is a question - each for one object or just one and just in one tick move all objects?)
I have some problem with some math i mean how to create a animation of turn. Tried to find this, but all i found was some spirals. I know there will be some use of Math Class + angle. (Some code, ideas or keywords for search would be nice.)
Sry for english if someone will have troubles to understand what i wrote.
The usual way it is done in games is by having one main loop. You can do this in WPF just the way you mentioned - make a DispatcherTimer, and update their position all during one call. Creating more timers is needlessly consuming resources for hardly any benefit.
Real car physics are relatively complex, but for your use case, you can go with something really simple. This is a great (and short) article on simple but good looking car physics: http://engineeringdotnet.blogspot.com/2010/04/simple-2d-car-physics-in-games.html
You can use XAML or Code behind to make animation. Here
I want to create collision vertices to attach to bodies in XNA with Farseer, according to loaded Texture2Ds.
A caveat, first of all. is that I'm not using Farseer for anything other than collision. Rendering and all other game code is done using my own engine. Farseer is just used as a background physics simulator (and will only tell me when a collision happens, and then I'll handle that myself).
I should point out here that I'm 100% new to Farseer. Never used it before.
So, if I create my List using BayazitDecomposer.ConvexPartition(verts), should I then store this data alongside the Texture2D objects; and then create List objects on the fly when I create my collidable actors? Or am I doing something wrong?
Furthermore, in the example at http://farseerphysics.codeplex.com/documentation, it scales the vertices by Vertices.Scale()... If I keep all my Farseer bodies in pixel space, do I need to do this?
Thank you.
So, if I create my List using BayazitDecomposer.ConvexPartition(verts), should I then store this data alongside the Texture2D objects; and then create List objects on the fly when I create my collidable actors? Or am I doing something wrong?
You create an instance of the Body class from a list of verts using the BodyFactory. I would suggest doing this for each actor you have. However, you can save yourself some processor power by reusing bodies. So if an actor dies add the body to a queue and then snap it to a new actor that is created.
Furthermore, in the example at http://farseerphysics.codeplex.com/documentation, it scales the vertices by Vertices.Scale()... If I keep all my Farseer bodies in pixel space, do I need to do this?
Nope. However that means that a pixel is a meter as far as Farseer is concerned. I believe the formula for Torque if Radius * Force so anything reliant on a radius wouldn't behave as expected. I suggest making the metes equivalent to what actually is a meter in the game. Its just a bit of extra division.