[QUOTE=sarge997;44922651][B]Unity 4.5 is out![/B]
[url]http://unity3d.com/unity/whats-new/unity-4.5[/url]
Hohoho, them bug fixes. Looks good![/QUOTE]
Is the new GUI out? No?
UNITY COME ON
HOLY SHIT Sparse Textures??
HELL YEAH.
Why wasn't that unveiled at Unite!?
the new scripting reference looks nice: [url]http://docs.unity3d.com/ScriptReference/Rect.html[/url]
[editline]27th May 2014[/editline]
[QUOTE]Made it possible to undo changes made to prefab assets.[/QUOTE]
Yes!
[QUOTE=KillaMaaki;44922945]HOLY SHIT Sparse Textures??
HELL YEAH.
Why wasn't that unveiled at Unite!?[/QUOTE]
I'm stoopid and I don't know what a sparse texture is.
Explain please.
[quote]Added Sparse Texture support (also known as "mega textures" or "tiled textures"). This is a low-level API feature, see SparseTexture class. Implemented on DirectX 11.2 (via tiled resources) and desktop OpenGL (via ARB_sparse_texture).[/quote]
Ah, that's pretty cool. Any references to it in action?
[QUOTE=sarge997;44923238]I'm stoopid and I don't know what a sparse texture is.
Explain please.[/QUOTE]
[QUOTE]Added Sparse Texture support (also known as "mega textures" or "tiled textures"). This is a low-level API feature, see SparseTexture class. Implemented on DirectX 11.2 (via tiled resources) and desktop OpenGL (via ARB_sparse_texture).[/QUOTE]
[editline]27th May 2014[/editline]
[URL="http://docs.unity3d.com/ScriptReference/SparseTexture.html"]http://docs.unity3d.com/Manual/SparseTextures.html[/URL]
Here's what makes mega textures REALLY cool.
Traditionally, games have dealt with limited texture RAM by heavily reusing textures, or by reducing texture resolution.
One thing mega textures lets you do is pack all of your level's textures into one big massive texture atlas, and then page bits and pieces of the atlas in and out of memory depending on what's in view. That lets you use bigger textures, and more unique textures.
EDIT: You can also load and unload mip levels independantly, so for instance if a texture is only used on a distant object, you can unload all of the higher mip levels and just keep the low-res version in memory.
[QUOTE=KillaMaaki;44923291]Here's what makes mega textures REALLY cool.
Traditionally, games have dealt with limited texture RAM by heavily reusing textures, or by reducing texture resolution.
One thing mega textures lets you do is pack all of your level's textures into one big massive texture atlas, and then page bits and pieces of the atlas in and out of memory depending on what's in view. That lets you use bigger textures, and more unique textures.[/QUOTE]
But doesn't unity limit texture imports to 4096x4096? And how does using a portion of a huge image (say 10k x 10k) compare to using a single image of the same size? Or is that not how it works?
[editline]27th May 2014[/editline]
Also, this new Module Manager sounds nice: [URL]http://blogs.unity3d.com/2014/05/27/module-manager-in-4-5/[/URL]
[QUOTE]One feature that rolled out with Unity 4.5 is the module manager. The module manager is a new system for us to be able to deploy updates to specific parts of Unity without making a complete Unity release.[/QUOTE]
[QUOTE]In upcoming versions of Unity, we’ll continue developing and extending the module manager by adding modular update support for more platforms (the goal is to eventually support updating all our platforms this way), as well as support for updating other Unity subsystems, for example the upcoming Unity GUI system. Additionally, we plan to begin stripping these things out of the base Unity installer, in order to provide you with a smaller Unity download and a faster Unity installation, along with the ability to download and install support for the platforms and subsystems you care about.[/QUOTE]
[QUOTE=Pelf;44923510]But doesn't unity limit texture imports to 4096x4096? And how does using a portion of a huge image (say 10k x 10k) compare to using a single image of the same size? Or is that not how it works?[/QUOTE]
AFAIK Unity's asset importer for Texture2D does limit it to 4096, but the same isn't true of the new SparseTexture (which can't be imported as a texture per se, but you can dynamically load/unload tiles of it).
It can be as big as you want, no limits. The only memory used is whatever tiles you have loaded.
So the benefit is that you can dynamically load only which textures you need into a SparseTexture and use it as if it were a texture atlas. If an object goes out of view, its texture can be unloaded from the SparseTexture which frees up space for something else to be loaded in.
EDIT 1: Or, in fact, it's even possible to only load in portions of an object's texture based on which part of that object is in view.
EDIT 2: You could also use one sparse texture per object - useful for very large objects where you could page in/out parts of that object's texture.
Conventional 10kx10k textures don't fit in most people's RAM's, hence they're sliced.
They are also easier to access when treated as a single entity.
As far as I can tell, the API is still pretty low-level. So we'd still have to come up with a way to analyze the scene and determine *which* parts of a sparse texture need to be loaded/unloaded based on what's in view and potentially their mip levels (if on a given frame a texture is only used on a distant object, you could unload the higher resolution mips in the chain since they aren't being used). But at least we have a nice handy way to page those textures in and out, and an easy way to use them from shaders.
Alright so I recently got interested in the double-slit experiment in Quantum physics, and for some reason I wanted to reproduce it in Unity3D, so I put up the wall, the slits and the particle shooter, and it turns out that it worked...
The simulation is speed up else it would be kinda boring, but you can see it somehow makes an interference pattern.
[video=youtube;M7V3Upwrr04]http://www.youtube.com/watch?v=M7V3Upwrr04[/video]
[QUOTE=Fleskhjerta;44928651]Alright so I recently got interested in the double-slit experiment in Quantum physics, and for some reason I wanted to reproduce it in Unity3D, so I put up the wall, the slits and the particle shooter, and it turns out that it worked...
The simulation is speed up else it would be kinda boring, but you can see it somehow makes an interference pattern.
[URL]https://www.youtube.com/watch?v=M7V3Upwrr04[/URL] (Video tags are somehow broken)[/QUOTE]
Just remove the "s" in "https" and it should work.
[QUOTE=MilkBiscuit;44922915]Is the new GUI out? No?
UNITY COME ON[/QUOTE]
I remember when it was all the hype when they announced new GUI @ 4.5...
what a joke
They promised it would be out in 4.6 somewhere.
What's the best way to handle physical bullets in multiplayer?
At the moment, when I shoot another player it *sometimes* hurts him, but sometimes doesn't, I believe its because the bullet has a tiny bit of lag on each screen. And I'm not sure how to get it working properly.
[QUOTE=sarge997;44931249]What's the best way to handle physical bullets in multiplayer?
At the moment, when I shoot another player it *sometimes* hurts him, but sometimes doesn't, I believe its because the bullet has a tiny bit of lag on each screen. And I'm not sure how to get it working properly.[/QUOTE]
Assuming you use a collider, it's probably because your bullet object moves too fast to register for collision. If it's an option, you can try raycasting instead of moving a collision object.
Well, its a top-down shooter.
I want the bullets to be visible, so player's can dodge them and what not.
[IMG]http://i.imgur.com/OORghXU.png[/IMG]
My projectile has a rigidbody, and a sphere collider.
Here's the projectile script.
[code]using UnityEngine;
using System.Collections;
public class PistolProjectileScript : Photon.MonoBehaviour {
public int damage;
public GameObject bloodObj;
public AudioClip[] sounds;
void OnCollisionEnter(Collision other)
{
if (other.gameObject.tag == "Player")
{
if(photonView.isMine)
{
PhotonNetwork.Destroy (gameObject);
}
PlayerHealthScript playerHealth = other.gameObject.GetComponent<PlayerHealthScript> ();
playerHealth.currentHealth -= damage;
GameObject blood = Instantiate(bloodObj, transform.position, Quaternion.identity) as GameObject;
blood.audio.clip = sounds[Random.Range(0,sounds.Length)];
blood.audio.Play();
}
else
{
if(photonView.isMine)
{
PhotonNetwork.Destroy (gameObject);
}
}
}
}
[/code]
I'm not quite sure why this code isn't working. It seems like it should work just fine, as its only removing the bullet if MY screen hits him..
[QUOTE=sarge997;44931304]Well, its a top-down shooter.
I want the bullets to be visible, so player's can dodge them and what not.
[IMG]http://i.imgur.com/OORghXU.png[/IMG]
My projectile has a rigidbody, and a sphere collider.
Here's the projectile script.
[code]using UnityEngine;
using System.Collections;
public class PistolProjectileScript : Photon.MonoBehaviour {
public int damage;
public GameObject bloodObj;
public AudioClip[] sounds;
void OnCollisionEnter(Collision other)
{
if (other.gameObject.tag == "Player")
{
if(photonView.isMine)
{
PhotonNetwork.Destroy (gameObject);
}
PlayerHealthScript playerHealth = other.gameObject.GetComponent<PlayerHealthScript> ();
playerHealth.currentHealth -= damage;
GameObject blood = Instantiate(bloodObj, transform.position, Quaternion.identity) as GameObject;
blood.audio.clip = sounds[Random.Range(0,sounds.Length)];
blood.audio.Play();
}
else
{
if(photonView.isMine)
{
PhotonNetwork.Destroy (gameObject);
}
}
}
}
[/code]
I'm not quite sure why this code isn't working. It seems like it should work just fine, as its only removing the bullet if MY screen hits him..[/QUOTE]
Is there a difference between the two screens? So, on one screen does he get hit and on the other he doesn't? If so, you probably want to make the shooter authoritative and let the shooter tell who he shot and with how much damage.
Well, I believe the problem is, since its not perfectly synced, as I said. Its hitting the other player perfectly on screen 1, but on screen 2, it passes through him.
So I believe you got the right idea on setting up some kind of authoritative script, where only if the bullet on MY screen that I fired, hits him, it takes damage.
Makes sense, but I'm not sure how I'd do this?
*Edit* I know what to do now!
If you have an explicit host, the client should let the host know who he is hitting, so the host can broadcast to all clients that this one client got hit by a bullet. Each client can then play the hit effect on the affected player gameObject and delete the bullet.
So what you have is a server, a single client that says "I'm player two and I hit player one", and multiple clients (say Player one, Player three, Player four, etc.) who each receive this message.
When player two sends the message, the server sends a new message to each client that "Player two hit player one". Player one, Player two, Player three, and Player four would then play the hit effect on the position of Player one on their screen, and Player one would take damage.
If Player one has taken enough damage, he says to the server that he died, which is another message that gets broadcast to each client except the sender.
Correct me if I'm wrong, but that would be my approach for a very simple authoritative client solution.
Hahah! I actually just did what you said, before you said it.
I absolutely love figuring things out.
Here's the changes I did.
Instead of this.
[code]PlayerHealthScript playerHealth = other.gameObject.GetComponent<PlayerHealthScript> ();
playerHealth.currentHealth -= damage;[/code]
I made it send an RPC to the hit player.
[code]other.gameObject.GetComponent<PhotonView>().RPC ("TakeDamage", PhotonTargets.All, damage);[/code]
Which executes this code on the player.
[code][RPC]
public void TakeDamage(int amt)
{
currentHealth -= amt;
}[/code]
But still, thank you so much. You had the right idea all along.
If you're using collider based hit detection, I would recommend against it in my experience. There is the special case where you need bullets to have a specific hitbox where you might have to use colliders, but for most bullet applications that doesn't matter, and I still fully suspect there's a better solution for that case as well.
I've had a lot of bad experiences with trying to get collider based hit detection to reliably work for bullets that move at anything faster than ~100 m/s so I do all my hit detection with raycasting now. Raycasting does not necessarily mean the bullet has to be instantaneous. The bullet is still a gameobject that moves through the world, but every frame (or FixedUpdate if you move it only in FixedUpdate) I do a raycast forward based on where the bullet will travel in one frame.
Below is the basic code for it. If the ray hits something, you can use rayHit.transform to get the transform of whatever you hit and from there you can get whatever components are attached to that gameobject and apply damage. You're probably going to want to do little tweaks to this like for example spawning the hit effect at the rayHit's location rather than where the bullet currently is, but those are all simple and easy to account for details.
There are still very specific cases where this might miss an intercept against targets moving extraordinarily fast, but in most cases the bullets will far outpace the targets they're shooting at so it's usually not an issue.
[code]// Create ray for raycast.
RaycastHit rayHit;
Ray forwardRay = new Ray(ownTransform.position, ownTransform.forward);
// Perform raycast using the velocity of the bullet and an appropriate hitmask. "rayHit" gives information on what was hit.
bool rayWasHit = Physics.Raycast(forwardRay, out rayHit, velocity * Time.deltaTime, hitMask);
// When a hit is detected, apply damage if destructible and apply splash damage if needed.
if (rayWasHit)
{
// Apply your damage here
}[/code]
hitMask is a mask that allows the raycast to hit only certain layers. My bullets for example only hit the layer that specifically contains the ships and other bullet-hittable objects in my game. Here's what that looks like if you want the ray to hit only layers 3 and 9.
[code]
int hitMask = 0;
hitMask = (1 << 3) | (1 << 9);
[/code]
I've always wanted to make a game, never actually arsed myself to actually learning how to like, program stuff. What I have so far is something I've thrown together from tutorials, but it's closest to a game I've ever gotten (not counting boardgames I've designed).
It's barely worth posting, basically 2D top-down view on a black square that has an arrow pointing at it commented "is tank" and the whole thing goes up, down, left and right. It was made from a pong tutorial so I figured the left and right thing myself which is absolutely freaking revolutionary. And even what I have so far is glitchy as hell and sometimes goes up when you're holding down left button. Well, it's a start I guess.
I aim to experiment with some ideas I have for a top-down vehicular shooter. First thing I'll be doing is dynamic camera where your vehicle isn't in the middle of the view, but rather at the bottom, and the camera rotates around it as you move your mouse left and right, kind of emulating traditional first-person camera in terms of responsiveness and field of view. Hopefully it won't be too confusing (shouldn't be due to simplicity of top-down 2D).
[img]http://i.imgur.com/kKPM5qp.png[/img]
New video on the new GUI system coming in 4.6.
[video=youtube;EOX6itCuKOc]http://www.youtube.com/watch?v=EOX6itCuKOc[/video]
[url]http://blogs.unity3d.com/2014/05/28/overview-of-the-new-ui-system/[/url]
It's really great to see they're stepping up the game and keeping in touch with the fans more than ever. It cannot be helped that people compare it with other engines all the time, but competition is always healthy in order to keep things going at a larger scale. I'm really excited on what uGUI can provide so far, and it shouldn't be far from release either. Having a native and unified GUI system on any platform without hassle is going to be a great feature.
It's going to be here soon guys, going to be here really soon.
Oh man. That GUI. I'm only 3 minutes in and I'm already seeing so much. I recently did GUI for the first time so I could have a HUD for my space sim but oh my God was it painful and disgusting and it's so bad and I hate the way it looks and it's so bad.
This is just leagues better. World space canvases also have me very excited because this means we have native support for GUIs that exist in the game world. That's amazingly useful and super great.
[editline]28th May 2014[/editline]
This actually has me [I]excited[/I] to make some kind of GUI rather than horrified at the prospect.
[editline]28th May 2014[/editline]
Image masks confirmed for easymode HUDs like in fighterjets. You can display the HUD content out like 1000m away from the camera, but the camera needs to look through a mask which exists in the HUD glass itself to be visible. I'm having trouble containing my hype.
Working almost as desired.
[img]http://giant.gfycat.com/AmbitiousExemplaryGreathornedowl.gif[/img]
Almost.
[QUOTE=Drury;44933975]Working almost as desired.
[img]http://giant.gfycat.com/AmbitiousExemplaryGreathornedowl.gif[/img]
Almost.[/QUOTE]
What might be easier for you to do is place a empty game object on the position of the tank, and then place the camera inside the empty game object. Then attach the script that rotates the camera on the empty game object, and just make it rotate around with no translation. This will cause your camera to rotate and translate correctly, and the tank will always be in the bottom of the screen.
[QUOTE=Asgard;44934031]What might be easier for you to do is place a empty game object on the position of the tank, and then place the camera inside the empty game object. Then attach the script that rotates the camera on the empty game object, and just make it rotate around with no translation. This will cause your camera to rotate and translate correctly, and the tank will always be in the bottom of the screen.[/QUOTE]
Empty Game Objects are black magic.
[QUOTE=HeatPipe;44934159]Empty Game Objects are incredible.[/QUOTE]
Fixed :D
*Edit* oh shit, 1337th post..
Sorry, you need to Log In to post a reply to this thread.