Niosop
-
Posts
1,124 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Niosop
-
-
Use DXT5 if you need an alpha channel (for spec, opacity, etc). Use DXT1 for diffuse only textures.
-
He's just saying that by the time the DrawImage command is called the Scene has already been loaded. So while the scene is being loaded, nothing is being sent to the video card, so whatever happened to be in video memory is going to be displayed.
-
I think TerrainHeight just returns the value of the heightmap normalized to [0,1] at the x,y location.
-
Are you using the new SSDO shader in the Editor and not in bmax?
-
Hmm, the ctrl + right/left click functions don't seem to be working for me. Any stupid mistakes I might be making?
-
Just beat Shadowgrounds. Not bad for an indy team. From the credits it looks like 4 programmers, 7 artists and 1 sound/music guy.
Update: Just fired up Survivor. Looks a LOT better, I'm impressed. Same basic game play, but camera control has been tweaked a little, a little more depth added (a little more RPG like feel), they moved to PhysX, lighting has been vastly improved, now there's spec on the textures. It looks a lot like what I'm going for.
-
Steam has a pack with Shadowgrounds and Shadowgrounds Survivor for $4.99. It's not the best game ever, but worth $5. I mainly noticed it because I'm working on something very similar right now so I figured I'd check it out and maybe get some ideas.
It seems to use a mostly dynamic lighting with some baked in lighting on the few non-destructible things around. Everything looks a little flat though. I think it might be due to lack of specular textures? Hard to say.
Anyways, just thought I'd mention it.
-
See, it's stuff like this that makes me glad to be using LE B) Frequent updates that address things that we ask for. Thanks Josh!
-
If we could assign an existing bone weight matrix to a duplicated mesh then we could create our own non-instanced copies of a model. But the API doesn't give us any access to it.
-
Yeah, I get the same effect. I think it's the background showing through, so it appears white in that scene. I think it's that the different raycasts miss that little area so it doesn't draw any occlusion information right along the edge so the unshaded background shows through.
-
I don't think he needs a unique selling point. Right now the visual quality of the engine IS his unique selling point. What he needs to do is stop looking for unique features and add in stuff that the other engines have that improve workflow and the asset pipeline.
Things to take from Unity:
* Visual in-editor physics and joint editing w/ constraint visualization. Or better yet, something like the UDK's PHAT editor. Having realtime physics in the editor is great but creating the physics assets is still a big pain.
* Clone their asset importing pipeline. You can't beat dragging an asset into the editor and having it be automatically converted and just double clicking the asset to automatically launch the associated editor for that asset, make changes, hit save and have it be re-imported into the engine. It's a MAJOR time saver.
* Prefab support - another HUGE thing we're missing.
* Multiple scripts per object - it's nice to encapsulate code into small snippets, then just add the snippets that are desired to an object. Much easier than opening the lua file for that object and adding in includes and function calls to include the code you want. And cleaner than making a thingoid that you have to drag into your scene and link to your objects.
* More than 5 terrain textures.
Things to take from the UDK:
* A static lighting baking option like T3D's PureLight or the UDK's Lightmass. Yes it's expensive in terms of additional texture memory required. But it can make a big difference when used judiciously and the fact that it's easily misused isn't a reason for not offering it at all.
* Node based material editor. The shader system in LE is already based on snippets that are conditionally included. This could be taken to the next level so that each material can have it's own unique shader that is built at startup AND REBUILT WHEN IT CHANGES. It's a big time killer to close the editor, edit the shader, start the editor, check the results, repeat. Josh has already said he'd like to implement this.
Many of these aren't engine issues at all and could be implemented w/ the current LE API. But they would require that we totally rewrite the editor from scratch to add them. Making a plugin system for the editor that would allow you to add your own menu items, popup windows, receive all events from the main editor process to act upon, send commands back to the editor, etc would allow us to write some of these ourselves and take some of the load off Josh.
Anyways, I think I've mentioned all of these before, but I think it's pretty important that these are addressed to stay competitive.
Just my $0.02.
-
The one on the left is being lit by primarily by ambient light, the one on the right is being lit by ambient light and the yellowish light being reflected off the sand.
-
GI and AO are NOT the same thing. AO only takes ambient light into account, GI takes all lights, the way they bounce and their color into account. And no matter how many times you say it, LE is not in the same league as CE3. It might be close as far as rendering, but it's the tool set that makes a development environment and LE isn't there yet. But it's within my price range which makes all the difference.
-
I think the biggest threat might be Unity moving to a deferred lighting system (ether entirely or as a swappable rendering subsystem). They have a bigger development team, more money, more users, can deploy cross platform and to browsers, a great editor, plus people can write stuff in the free version and upgrade when they want the Pro features. LE's big advantage is visual quality, so if that gap is closed, LE doesn't really have any advantage anymore.
I think the one big thing that Josh can do is make things more accessible to us, enable us to disable subsystems (Audio, Physics, etc) so we can replace them if desired, expose as much of the engine as possible at as low a level as possible so that we can contribute to the development, fix bugs, add features. Make the editor support plugins and expose all editor events to these plugins so we can contribute plugins back to the community. I'm really impressed with what Josh has done, but he can't do it all alone, as shown by the number of bugs in the tracker that are unresolved and the shear number of feature requests.
All that being said, I really do like LE, enjoy developing in it, and look forward to what Josh is going to do with it next. The price is great and well worth picking up a license even if you're not sure that you'll end up using it for your project. The community is knowledgeable, helpful and generous with code and assets.
-
Yes, it's a symptom of the updated shadow caching system. It's not realizing it's cache should be invalidated for some reason, but don't have source so can't do anything about it
I think it will probably be a quick fix for Josh though. -
Does it for me on Dynamic and Dynamic+Static+Buffered and Static (if I move a static object). Dynamic+Static works intermittently for me, an objects shadow will follow it properly for a little bit, then get stuck in the same place for a few seconds, then jump back to the object.
-
Can anyone else confirm this? In the editor (haven't tried as a standalone program but I'm assuming it's the same) shadows cast by a spotlight never update. So it "bakes" the shadow onto the terrain/other objects. This is only for spotlights, point lights work fine.
-
I have some animated models moving around. The SSDO induced darkening doesn't update when they move, effectively baking the SSDO effect onto other objects/terrain.
Hmm, might be something else, just returned to the original shader and it's still doing it.
-
Forget Torque3D. They have some cool demos, but from everything I've seen and heard, the codebase is a mess.
Unity is a great engine, but it is built to run on a wide variety of hardware. You can write shader code that is conditional on it being supported by the card w/ fallbacks to other techniques if the preferred one isn't supported, but it would involve knowledge of writing shaders and what different generations of cards support. It's editor is a little more friendly than LE's is, and it does a little better job of exposing engine functions to the user than LE does at this time. You'll also have to pay 7.5 times as much as LE to get the Pro version to get real time shadows, which you can't really live without for the type of game you are talking about. Unity's performance profiler and asset streaming system are some advantages it has.
LeadWerk's rendering engine looks awesome and it's editor is pretty good. There are some rough edges, but Josh makes frequent updates to try and address these, although keep in mind that your priorities are not always going to be his priorities as far as feature additions/bug fixes. You can expect new features/fixes to come out for LE every few weeks, whereas Unity seems to release bigger updates every 6 months to a year.
I'm currently doing parallel development in both LE and Unity. I'm more productive in Unity usually because of it's asset pipeline and how polished the system is, but the same scenes using the same assets tend to look a little better in LE.
So between LE and Unity, they're both great but different. For your project, LE is probably a better fit as it has a more advanced lighting system and offloads a lot of stuff to the GPU. And Unity costs 7.5 times more and definitely isn't 7.5 times better, so LE wins hands down as far as bang for your buck goes.
I'd say try the demo of LE and download the Unity free version and play with both so you can get your feet wet without shelling out any cash. That should give you a better feel for what works best for you.
-
Seems like it adds a shine or glow around the edges of objects. I hadn't tried tweaking the values yet.
-
If you have an .obj version of it I'll be glad to take a look at it and see if I can fix it.
-
Check the faces that are appearing black. If your modeling program supports it, have it display the normals or turn off two sided rendering. Then you can see if those faces are facing the wrong way and flip the normals on those if needed.
Actually looking closer at that picture, it seems that it's definitely just that those faces just need to be flipped.
-
You want either itoa or sprintf to convert the integer 5 to the string "5". As it is you're telling it to try and make a string out of whatever is at a memory location, which will cause a crash.
Probably something like this:
int i = 5; char a[30]; strcpy(a, "SCORE "); char buffer[30]; itoa (i,buffer,10); strcat(a, buffer);
-
Try it with just a diffuse map, no normal map. If the problem goes away then it might be that the Y component of the normal map is inverted. If the problem doesn't happen when only using a diffuse then you can try adding:
normal.y *= -1.0;
right after:
normal = bumpcolor.xyz * 2.0 - 1.0;
in mesh.frag and see if that fixes it. If so, then you can leave it like that if all your normal maps are generated the same way, or use -Y in your normal mapping program and leave the shader the way it is.
I think it will probably be a quick fix for Josh though.
force on a body
in Programming
Posted
Yup, then you'd apply a Vec3 like (0, 1, 1) which would be a 45 degree angle if you are using it's local coord system...or it might be -1 for the Z component...Scale the Y and Z to adjust force, so it might be (0, 50, 50) or something.
AddBodyForce applies the force to the whole body, so you don't need to worry about applying it to his midsection.