Flexman
-
Posts
916 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Flexman
-
-
They are fun to listen to, like an LE podcast.
If you're taking ideas for advanced tutorial topics in the future, video examples of different kinds of joints would be nice. Moth AI and suchlike
-
Ah I see what you mean. It's not quite the same model, two compounds built the same way, different exporters.
I'd really like to know what the big size difference is about, there's a performance hit too, noticeable with a 30k poly cockpit.
-
Couldnt you just blend the models "off" at a certain distance?
And for roads you could use a complete black alpha in the last mipmap sp it would be invisible too.
Or work with fog and some distance before you get zfighting.
Alas were it so simple.
Roads are a bit odd actually. Out at the near 20k unit region, they do wibble a lot (I like that word), in the middle distance they appear steady. I'm quite intrigued by that.
We're able to mitigate some effects using LODs and object visibility range settings, 2.32 has more options we'll be using. But still have depth issues as we have up close objects everything in between for 6,000 or so units.
It all goes to hell when you have something like a sniper-scope though. You're rendering a narrow frustum with objects up close and everything out to several km.
There's also the issue of floating point accuracy which an accurate zbuffer can't fix and needs Ogre3D style camera relative rendering. My workaround for that is to simply not have the cockpit occupy the same world and fake lighting to match; after the main world render, clear the z-buffer then render the cockpit with ambient/sun light. Live with the other visual artefacts, which it has to be said can be seen in other games to a lesser extent.
I've been chatting with the Outerra engine designer about his technology, very nice chap, it's currently OpenGL, surface to whole planet rendering. Way way beyond the scope of what we need for our current game. 40x40km is the biggest LE lets you make which is spot-on perfect for our game. I just want it to look steady, as best as we can.
If it's reasonably straight forward to add your own z-buffer shader function to improve shadow rendering and depth resolution then great. But there has to be a catch?
-
Is it really a Dexsoft/model issue though? When I started last year looking at model import/export I tried a Dexsoft pack or two and UU3D and got similar results. Two different packs by different authors. I used the official exporter in 3DS MAX and all those problems went away. Everything I exported with UU3D was terrible.
But it doesn't stop there...take the two 3DSMax exporters..here is the same model side by side.
Arbuz's unoffical exporter on the left and the offical Leadwerks export on the right...(see image below)
Quite a difference there too. And that's trying to use matching settings (I'm having cockpit export issues and working out why I get different qualities and sizes using the different MAX exporters).
But UU3D always gave me problems, I stopped using it for anything other than quick placement. I think the GMF exporter it needs updating or something.
-
You might need to explain a little more about what this second window is. Is it a "picture in picture" a rectangle showing another camera view, or a an O/S type window, or an app window with multiple viewports like a 3D editor?
-
The larger scale maps you're able to create with Leadwerks engine are a little over 40km x 40km assuming 1m per unit and a terrain of 4096x4092 with 10m per tile.
If you've ever tried positioning object with small details at positions more that 10,000 delta from the origin you begin to run into z-buffer artifacts. It's a problem common to most engines.
A good explanation of this can be found in Steve Baker's document on Loving your Z-buffer.
This is something we have problems with. Even roads, large as they are flicker towards the outer areas of the map.
Then someone pointed me towards a blog post about using a Logarithmic Depth Buffer. In which he references Steve Baker's doc and an interesting solution which allows his 3D engine to render near and far objects with impressive resolution.
A similar kind of z-buffer in LE would fix some of the ugly z-fighting you get further out.
This YouTube video of
is just nuts. Looks highly specialised, but cool. -
I liked the grammar Nazi, don't see many of those on the internet anymore.
This is a nice take on RPG heros and the mechanic of looting everything you find...
-
Is there a way to turn off child objects from being occluded? I'm sitting in a cockpit and chunks of it keep vanishing when I turn my head.
The other occlusion problems I had have been fixed.
-
Yeah I like that.
One ping only please.
I remember this really super modern sub game years back that was played using mostly the "waterfall" sonar display. I'd just bought a Gravis Ultrasound audio card and having to listen to find contacts and use the sonar heat-map was really cool.
SSN Seawolf maybe? Don't recall the name. Think this might have been it. Wiki Link
I haven't played a sub game as good as that since, except maybe the somewhat buggy Silent Hunter 4. And version 5 is visually stunning has a DRM line I won't cross.
-
I'm having problems identifying what combination of joints would work best for this.
Think of the undercarriage of a bomber.
The wheel spins around and fixed to two 'rods',
Rod a - A shock absorber that goes up/down
Rob b - Fixed shaft (the long diagonal) that attaches to the aircraft and wheel.
I'm not sure how I should be building this. *scratches head*
-
mass looks a little light. Been a while since I played with the vehicle physics, I wrote a little program to adjust those settings as you drive and typically good results for a vehicle with mass set to 11, was the damper at one half the constant...or the other way around.
I should really check. The mass and springs work against gravity which by default is set to 20.0 and not 9.8. So try upping the mass of the vehicle.
Actually I have a physics question myself, I'll post that in another thread.
-
I'm excited by the idea of having pre-compiled road data but maybe if it's going to be binary it should be saved as a "roadmap.bin" file with the SBX just containing the filename of the data. Saving binary data in the SBX is asking for trouble. Opening the SBX in a text editor is handy for quick search/replace changes for example, and binary data in the file is just going to kill that. And isn't it possible that the binary data might appear as an EOF end of file marker or some such? Am I still living in the 20th century? (I used to write COBOL).
Anyway, veg data is binary and saved externally, road data should be too IMO. It's a cool feature to have.
-
Ditto, I'm using the LE 2D font drawing too.
-
Yeah it depends. Stuttering from asset loading can annoy so I tend to do those things in game moments where it's not noticeable or going to be a problem. Don't think there's any hard and fast rules.
-
-
DAZ3D models are prevented from being used in games by the EULA. With new tools and a store aimed at game developers, it opens the way for some of the models to be used in games. Worth investigating.
http://forum.daz3d.com/viewtopic.php?t=139026&trid=972675403
-
I ended up making a GameFont class as a wrapper for the 2D font drawing. Once you change from the default font there's no obvious way to get it back. I don't think your missing anything.
-
I'd be tempted to call it "Groundwerks" as you're starting from the ground up
but you wanted a smart name.It's all very interesting. I like the idea of having cells paged in if it didn't cause too much stuttering. Microsoft FSX did loading and preparing terrain cells in another thread and every alternate frame to spread the load. This doesn't seem like an easy task but I'll be following what you do with it.
There are other possible issues to resolve too, physics, world size and floating point error. Camera relative rendering would go a long way to fix juddering I think but I don't know enough about the LE internals to even guess at how you could make that work. Just Cause 2 uses 64 bit floats for all positional data to deal with that problem. There's a feature on it somewhere I'll try and locate.
But kudos to your approach. I hope it can be made to work. Thumbs up here.
-
Well I don't know if this is of much help.
The simplified hierarchy is as follows:
Helicopter > Rail > Pivot > Missile
There's nothing unusual in how I parent these. I don't apply any scaling or transformation. Objects are created in code and all 3D objects are exported to the same scale.
The only different between these two images is what I parent the missile to. Correct when on a pivot, incorrect to the rail. The rail is a separate object that is parented to a natural child of the Helicopter model. *shrug* not a clue what's going on here but pivot works for me so I'm happy.
-
I sometimes get some strange effects parenting, scales of objects changing, uncommanded orientation. So if I need to parent anything I'll attach it to a pivot then Move the entity into position.
FWIW here's an example of how I add missiles to rails on an aircraft.
HellfireEntity[NextRail].SetParent(Self.PylonPivot, 0) ; HellfireEntity[NextRail].Move(RailOffset[NextRail], 0) ;
Where RailOffset[] is an array of Vec3 defining offsets of missile mount locations on the rail. Not saying don't parent, just that sometimes it can yield unexpected results. It's also handy.
-
Well to explain a little I'm building an environmental system to control dynamic weather. And I wanted to keep it simple by taking the lua Atmosphere entity and over time pushing different parameters to it. Accessing it through the framework was causing exception errors as the skybox was not available (=null). This turns out not to be so strange, as I'd removed it in the editor
You're code snippets I'm familiar with, I used them to learn and setup scripting at the start of the year for which I am grateful.
Sorry if I come across as being a numbnuts at times. User at fault :/
-
Here, the program creates a skybox just by loading the environment_atmosphere model. Make sure you have the scripts folder copied to your project directory:
LoadModel("abstract::environment_atmosphere.gmf");I have a question about this.
In C++ or bmax, how do you access the properties of the "environment_atmosphere" object? If you wanted to change the fogcolor, or
skymaterial for example?
And sorry for re-spawning a fairly old thread but it seemed a relevant question and searching didn't yield any clues.
-
Thanks gentlemen for both interesting suggestions.
Anything that's co-planer is out of the question you get a lot of zbuffer issues around the outer regions of the map. Lot of flickering around the base.
We did find a compromise that works quite well. Using mesh_contor.vert with mesh_diffuse_alphatest_terrainnormals_terraincolor.frag.
It blends the base reasonably well and fits it to the terrain without much flicker. Adding some rocks and other relief debris around it is a good idea.
Thanks all.
-
1
-
-
Thanks for the reply Aggror, good to know there are no issues.
but you wanted a smart name.
Rocks in mountain
in General Discussion
Posted
This isn't a practical suggestion, just something that I think is pretty cool. Horizontal Displacement mapping.
Using shaders to apply fractal noise maps to pull out natural looking surface detail. Pretty advanced stuff, like a lot of things in GPU Gems (available for free in HTML format here) it leaves me scratching my head.
http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=503094
Clicking on this next link may induce a feeling of apathy and weeping (Gamedev journal showing recent progress).
As mentioned in an above post, some good rock models (Pure3D has a selection in his store) can be used to create nice cliff sections. See the