I'm working on a 3rd person game built on Three.js where the user has free orbital control of the camera.
To enhance player experience, I'd like to use an outline on the active character that the user is controlling (there can be more characters in the scene), but only show the outline when (a part) of the player model is occluded/behind something.
Example:
The effect I want to create is shown on the far right (Stencil: 1), but instead of an opaque effect, I just want the outline as shown on the other models. There should be no outline on the visible parts of the player character, but only when the character is either partially behind another object or completely.
Now, the outline effect itself isn't really a problem. There are more than enough resources/examples/tutorials/whatnot about that. The part where I'm stuck is how to combine something like this with the occluding part. There is also the part about performance. If at all possible, I would really like to avoid rendering my entire scene multiple times for performance reasons.
Thanks in advance!
Using threejs R88 / 89-dev.
Related
I'm completely green when it comes to skeletal animations in 2D. I create a platform game and I got graphics for it - body parts from which to stick the character. My problem is that I have absolutely no idea how to go about it. The question is: How do you implement animations in the game?
I could do it frame by frame from previously glued body parts, but I need the character to look at the mouse cursor, so it falls off. I am asking for some ideas.
About your problem, if you want all parts of your character look at the mouse, you should rotate your character, if just a part (like character's head) you need to rotate the head.
I could give you some methods to implement animation that I known
Draw animation frame by frame: simple, easy to approach and handle but hard to scale up.
Separate character into many parts and each part has a unique animation: flexible, good for scale up but hard to handle due to you must ensure all parts are stick together in a right way (from scratch without tools or engine). I think this video may help you to know more the way their create skeletal animation in Unity (same as Spine).
Hope it help.
I'm working on a project that uses a lot of lines and marks with the camera at a very low angle (almost at ground level). I'm also using an outline effect to highlight selected objects in different ways (selection, collisions, etc.).
Native AA is lost when using postprocessing effects (eg: outline effect). This causes jagged lines on screen, more noticeable when the camera is closer to ground level.
I have created this jsFiddle to illustrate the issue (using ThreeJS r111):
https://jsfiddle.net/Eketol/s143behw/
Just press mouse/touch the 3D scene to render without postprocessing effects and release mouse/touch to render with it again.
Some posts suggest using an FXAAShader pass will solve it, but I haven't had any luck with it. Instead, I get some artifacts on the scene and in some cases the whole image is broken.
So far my options are:
Get a workaround to get the outline effects without postprocessing effects:
The ones I've seen around (eg: https://stemkoski.github.io/Three.js/Outline.html) duplicate the meshes/geometries to render a bigger version with a solid color applied behind the main object. While it may be ok with basic static geometries like a cube, it doesn't seem an efficient solution when using complex 3D objects that you need to drag around (objects with multiple meshes).
Increasing the renderer.pixelratio value to get a bigger frame size: This is not an option for me. On my test it doesn't make a big difference and also makes the rendering slower.
Try to get FXAAShader working without artifacts: As I said, it doesn't seem to fix the issue as well as the native AA does (and it is not as compatible). Maybe I'm not using it correctly, but I just get antialiased jagged lines.
Question 1: It may sound silly, but I though there would be an easy way to send the antialiased image directly to the composer or at least there could be some extra pass to do this, keeping the native AA. Is this possible?
Question 2: Maybe using Scene.onAfterRender to get the image with native AA and then blending the outline effect somehow?
Question 3: Googling around, it seems this issue also affects to Unity. In this post, it says this won't be an problem with WebGL2. Does this also apply to ThreeJS?
Is there a way to make a mesh unprintable with a 3D printer, but still viewable with three.js.
Motivation is that I want to show users a preview of a mesh before he can buy it. But as the JS code is viewable he could download it without paying for it. Degrading the quality of the preview mesh would be a way, but as the quality of the mesh is a selling point I would like to avoid that.
My idea was to add some kind of triangulation defects which would prevent the printing of the mesh, but which would not prevent threejs from showing the mesh.
Tools like Netfabb or Meshlab should also not be able to automatically repair the mesh.
Is there something like a bad sector copy protection equivalent for 3d models?
Just a few ideas.
1) Augment your shaders to ignore some interval of vertices from the buffer (like every 3rd or something). In this way you can add "garbage" to the model file so it can not be lifted easily from the network.
2) Once in the buffer it can still be pulled out with a savvy user, unless you split the model up into many chunks and render out of order or only render the front half of the model making it less useful for 3D printing. One could also render in split views or using stereoscopic interlaced with a separation of zero.
3) Only render a none symmetrical half of your model with an camera control locked to that half :P
Kinda wonky, a ton of work to implement, and still someone will find a way I'm sure. But that's my two cents worth anyway, hope it helps.
I've seen some online shops preview with renders taken from each 10-30 degrees around the model. That way you only pass the resulting image, not the model.
why not show a detailed HD video of your model?
If the mesh is non-manifold it will not print.
a) Render serverside, stream results in an interactive video
b) destroy the mesh while still keeping the normals intact for shading. You can randomly flip faces, render with double sided. You can "extrude" edges to mess up topology. As long as you map the normals correctly, it will shade without any of these defects affecting it.
I'm looking for advice more than direct help.
I am working on an 8 bit platformer game in XNA. I've probably sunk 160 hours into it already, and I'm starting to get into issues with the engine I have. It is basically an adapted/modified version of the XNA platformer demo. All or most of my tiles are 32x32, but some are 64 wide and 32 px tall, like a desk. Some are 32 wide and 64 tall, like a plant.
I am shipping them to the gpu just one .png at a time similar to the way that the XNA tutorial's author does tile mapping. For animated sprites I do use a tile map of different frames of the character. For the tile map data, I read in a text file just like the XNA tutorial.
How should I accommodate for the wide and tall tiles? Should I make a two layered tile system (I figured I should abide by the keep-it-simple-stupid rule)?
Right now I'm using transparent tiles to extend the wide tiles.
Desk with chair:
chair http://dl.dropbox.com/u/8446900/game_screen_desk.png
.....
...h.
..d".
#####
Plant and chair:
desk http://dl.dropbox.com/u/8446900/game_screen_plant.png
..p...h.
..,...,.
########
The chair is 'h', 'd' is for desk, 'p' is plant, and ',' is for a transparent background tile (no interaction with the user). '"' is for a transparent tile that the user can stand on (extending the desk). The problem is, as you can see, the background appears to have a hole in it.
Should I make an actual tile map and combine everything into one large png? Another option I could take is to actually cut each wide or tall tile into two different tiles. How would a pro do this? I'm not looking for a quick and dirty fix, just how a modern day platformer would run.
UPDATE: After reviewing the answer, I found a very useful tool that packs sprites into a sheet.
http://spritesheetpacker.codeplex.com/
UPDATE: My newly upgraded tile engine is much faster and almost just as simple. The advice below was great. Strongly recommended.
First off - don't introduce special-width/height tiles. Make the artist slice up large objects into single tiles (and hence re-compose them on the map editor). Every tile should be a PNG with an alpha channel so they can be correctly composed.
Keeping that in mind, my recommendations are:
Your tiles should comprise of only single tiles that have pre-composed parts of different objects, for example the left part of the desk is a single tile, the right part without a chair is another and one more with the chair behind it. (tilevalue = "dc", perhaps?)
You can define multiple layers of single tiles and render them back-to-front. You can also define a parallax factor for multiple layers and thus get a nice parallax effect between two layers quite easily. Of course, the player must "exist" in one layer at a time or you won't know what collision geometry to use for his/her current position.
You should also not create one texture per tile - but a compiled tilesheet (exactly like a spritesheet) so that the number of renderstate changes you make are minimized. Making many changes per draw call is bad because each time you make a change (current texture, drawing color or something else that affects that draw call) the API, the driver and possibly the GPU itself has to do work to update its state - this adds up quick.
Note that this doesn't mean you should put characters and levels into a HUGE spritesheet - this is bad for other reasons. You could, for example: put all level-related tiles in one tilesheet, the hero's animation tiles on another and all enemies on one (together) or something similar.
Hope that helps, otherwise I'd be glad to explain things further.
I'm new to Cocoa and looking for a little advice for an application from experienced Cocoa-ers.
I'm building a basic OmniGraffle-style app where objects are drawn/dragged onto a canvas. After the objects are on the canvas, they can be selected to modify their properties (fill color, stroke color/width, etc.), be resized, moved around to a new position, etc.
To get warmed up, I've written a basic drawing app that creates objects (circles, rectangles, etc.) as drawn by the mouse on a custom NSView, adds the objects to an NSArray collection, and renders the contents of the collection into the view. I could continue in this vein, but I'm going to have to add support for detecting object selection, resolving z-indexing, focus highlighting, drag handles, etc. with all the associated rendering. Also, rendering every object on each cycle seems terribly wasteful.
It seems like a better approach would be to drop lightweight view objects onto a canvas that were able to detect mouse events on themselves, draw themselves and their focus rings, and so forth. However, while NSView seems like an object with these properties, I see a lot of chatter on the web about it being a heavyweight component with a lot of baggage. I've stumbled across NSCells and have read up on them, but I'm not sure if they are the right alternative.
Any suggestions? If you can nudge me in the right direction I'd greatly appreciate it.
First rule of optimization: Don't do it first.
A custom NSView per shape sounds about right to me. Whether you'll want different subclasses for different shapes will be up to you; I'd start out with a single generic shape-view class and shapes able to describe themselves as Bézier paths, but don't be too strict about holding to that—change it if it'd make it easier. Just implement it however it makes sense to you.
Then, once you've got it working, profile it. Make as many shapes as you can. Then make more. High-poly-count shapes. Intersections. Fills, strokes, shadows, and gradients. You probably should create a separate document for each stressor. Notice just at the user level what's slow. Then, run your app under Instruments and look into why it's slow.
Maybe views will turn out to be the wrong solution. Don't forget to look into CALayers. But don't rule anything out as slow until you've tried it and measured it.