|
Post by rotary on Apr 19, 2012 9:14:40 GMT -5
Dissapointing news. It appears CryEngine3 currently has severe limitations which have no ETA for a fix yet. Maps bigger than say 1km give serious problems with physics and flickering due to rotational/positional accuracy. This seemed to have partly been caused by the fact that the engine had to be compatible for consoles (FP32->FP16).
For your information, the HardWar world is around 20km across. Until I am sure that they will fix this issue, I will stick to modeling assets. They know this issue excists, but they are very busy and I hope they plan some time to fix this. I'll let you guys know it when I know more.
|
|
|
Post by ouch on Apr 21, 2012 14:35:30 GMT -5
Have you tried ogre3d? It's what I use when I play around with making my own game.
It's capabilities and speed has certainly grown over the years. And the community there is absolutely fantastic.
|
|
|
Post by rotary on Apr 21, 2012 22:32:03 GMT -5
Well, tried is a big word.. I certainly looked into the thing to migrate to Ogre3D, since there is a conversion-kit that migrates your blender-file to ogre that really caught my attention around a year ago. Reason people do this is because of its much stronger graphics-engine. Downside: requires C++ and doesn't use python (in which all my stuff is written in the blender version). I must agree it's pretty discouraging to hit limitation on every engine you try.. Some motivational picture should accompany this (DONE!) Solution to the previous problem with CE3 is removing the terrain and inserting a custom-terrain and a script that resets position-errors (like reseting all positions after the player moves outside a certain range). Although I'm no fan of that, it still beats Ogre/Blender graphic-wise, and program-wise it doesn't take much more (LUA is pretty similar to python). However, since you have more experience with Ogre than me, feel free to convince me Attachments:
|
|
|
Post by ouch on Apr 22, 2012 2:29:29 GMT -5
Well there is a wrapper for python: www.pythonogre.com/But the best engine to use is the one your comfortable with using, because if your not then whatever it was you were doing will likely never get done. I've tried most if not all the free/open source engines out there and settled on ogre myself. One thing that attracted me to it was the ability to use nearly every physics engine out there. Most of the big ones even have wrappers for the engine as well. Downside to ogre is that it's a rendering library, not a game engine. There are a few projects out there that adds a game framework on it but most you have to pay for...
|
|
|
Post by rotary on Apr 22, 2012 14:41:12 GMT -5
Hmm, didn't know about that one yet! The fact that it is actually made for rendering (like blender) is holding me back. The things Ogre/Blender can do with rendering, CE3 can do real-time.
But the most comfortable engine is still Blender for me (although its limitations are too big). I still model basic shapes in Blender just to give some finishing touches to it in 3ds Max, and export it to CE3. 3DS just takes some getting used to I think.. The issue with CE3 is known by the developers, and more and more people are starting to push them to fix this (of which I am one) ;D, since it is becoming a nuisance.
Today I've been experimenting with VisAreas. Hangars can now be made pretty detailed, since they will not be drawn unless inside or when you can peek inside via a door/opening (it is still physical there though). At the moment the hangars are pretty big (too big?), I made one 100x50x25m. It fits in the building, but other buildings will certainly have to settle with smaller hangars (thereby decreased capacity). Current moth (moonmoth) is around 13m long, to give you an idea.
|
|
|
Post by ouch on Apr 22, 2012 16:46:40 GMT -5
heh, I think you mis-understood. ogre is a realtime rendering engine just like the crysis engine or the unreal engine. The difference is that ogre is not considered an game engine because it doesn't have things like, input, sound, or even physics built into it. There is also no "game object" framework. What I mean by that is that there is no built in first person shooter character object class for instance. That might sound bad, but it's actually a good thing because ogre is highly modular. For instance you can use Bullet physics, for the part in your game where your flying around in space, Physx once your on a ship, and ODE once your on a planet. So Your not limited to just one physics engine, nor are you limited to using that one physics engine the entire game. Ogre basically gives you complete freedom on how you want to make your game. It doesn't force you to use one library over the other. And because of it's modular/plugin style you can easily tack on any library you want if someone hasn't already created the framework for it. But it's this freedom that some people dislike. Some just want to sit down and start making their game without the hassle of choosing all the parts they need. For those people, game engines like the Crytek engine or the unreal engine exist. There are some game engines that use ogre. The largest is probably the neoaxis engine. But that one your forced to use C# which is just Microsofts .net. I personally find C# to be a horrible programming language. But each his own I guess... I think Ogre is the best of the open source engines out there, but the best proprietary engine out there I think is the unreal engine. Almost all the last big name games I've played have used the unreal engine. And for good reason too, that engine is solid, very fast, and has all the features anyone might need for any type of game. But if your stuck in python land then it might not be the best choice either... btw, sounds like VisAreas is just a way to manage scenes. Ogre has several different types of scene managers that you can choose from.
|
|
|
Post by rotary on Apr 22, 2012 19:11:43 GMT -5
Ah yes, I misunderstood you then indeed. Flexible in general is good, if you know what you're doing that is.. ;D
Within CE3 I also partly create my own entities, simply because stock-objects are not sufficient, and I want to make it editable via LUA later, so that you don't rely on recompiling of the code, nor have to rebuild it in the editor after every mod/edit. Some things like lights, physics, texturing, tesselation (you should check that out.. It's sickening powerful), and shaders are simply so useful, that it would be a pain for me to get to that level in Ogre. I'm not sure though if there is such a thing as copyright on shaders, and if Ogre could use them. As far as I knew Ogre was a graphics-engine that did well compared to blender, but is still quite behind the bigger commercial engines, or am I wrong here?
|
|
|
Post by reaxion2 on May 24, 2012 6:44:45 GMT -5
Not to make your choices any harder, hehe... but check this out.
Licensing
Use of the UDK for noncommercial purposes is free of charge. If you are going to use the UDK for any commercial purpose or in any way that is not specifically authorized in the end-user license agreement (EULA), you must agree to appropriate commercial terms. You can read more about these options below.
This is for Unreal Engine 3. FREE for non commercial purposes, and uses a scripting language. I didn't get into it very much, but this has the capacity to explode Hardwar to a level where we could all play on the same server.... everyone who wanted to ATM anyway. Plus the graphics, AI and physics would definitely be smoother.
|
|
|
Post by reaxion2 on May 24, 2012 6:49:18 GMT -5
I will try and see how much of this I can figure out, cause it sounds.. erm... UnReal. LOL
|
|
|
Post by rotary on May 27, 2012 9:05:18 GMT -5
By map-size, UDK should just be able to run a world with the size of hardwar. I peeked at it several times actually, but another change of coding-language made me hesitate every time again. Also the image of Quacke/Doom type of graphics (quick, jumpy, ugly monsters, etc) made me feel less attracted with UDK, although I know this is just my imagination playing up when looking at current graphics . I read somewhere though, that UDK had similar problems with accuracy, so I am trying to find out if that is true.. If not, then I am considering switching (again..) to UDK. The biggest issue with switching is that all the logic will has to be rewritten and discovered. I also don't know how deep the scripting in UDK can go, since coding is a bit outside my comfort-zone, as I have no experience with UDK's engine. For the rest, I barely got spare time nowadays, so it's difficult to update even on a weekly basis, so forgive me for that
|
|
|
Post by rotary on Jun 18, 2012 20:16:44 GMT -5
Ok guys, got news ;D
This nasty bug has been bothering me for a while now, and I'm not really sure whether CryTek will fix the issue, so I've been playing around a bit and found a way to fix partly evade the problem of inaccuracy.
The bug would cause all close objects to look shaking erratically when the viewer is further than 1km from origin. The solution is actually pretty obvious, but has more consequenses than just the obvious ones. Instead of using the built-in terrain system, I remove it, and create my own terrain 'objects'. This way, instead of letting the person move around a terrain, I let the terrain move around the person (in steps of say 100m). It seems to work pretty well until now, however things like smoke, fire, etc (particle objects) still live their own life, so I have to find a way to really make every single object move according to the player his movement. There are more problems ahead (as I heard of) since objects outside the original playing-area tend to behave unexpected (physically) for objects were never supposed to exist outside of the area. I'm trying to create/isolate/solve the problems that are coming with this solution.
To be continued...
|
|
|
Post by riedquat on Jun 22, 2012 13:28:29 GMT -5
umm... over-doze of relativity...
|
|
|
Post by Denacity on Jul 13, 2012 4:09:23 GMT -5
Ok guys, got news ;D This nasty bug has been bothering me for a while now, and I'm not really sure whether CryTek will fix the issue, so I've been playing around a bit and found a way to fix partly evade the problem of inaccuracy. The bug would cause all close objects to look shaking erratically when the viewer is further than 1km from origin. The solution is actually pretty obvious, but has more consequenses than just the obvious ones. Instead of using the built-in terrain system, I remove it, and create my own terrain 'objects'. This way, instead of letting the person move around a terrain, I let the terrain move around the person (in steps of say 100m). It seems to work pretty well until now, however things like smoke, fire, etc (particle objects) still live their own life, so I have to find a way to really make every single object move according to the player his movement. There are more problems ahead (as I heard of) since objects outside the original playing-area tend to behave unexpected (physically) for objects were never supposed to exist outside of the area. I'm trying to create/isolate/solve the problems that are coming with this solution. To be continued... If the terrain moves and not the player, how is that going to work for multiplayer?
|
|
|
Post by rotary on Jul 14, 2012 15:50:39 GMT -5
If the terrain moves and not the player, how is that going to work for multiplayer? I'm not very much into network-stuff yet, so I can't give any details just yet. Biggest deal is to create an offline version first! Basic idea will be that the client gets the information of the positions of closest moths (maybe combined with view-range, since it works similar) and place corresponding moths on the proper position relative to the player. CE3 has a built-in multiplayer system, but I am not sure how much I want to use that. This depends how much I can code network-code from code inside the game. The standard system comes with several drawbacks like player-limits and does not properly support map-sizes over 1km square, let alone moving terrain. I already use my own 'code-box' that does much of the logic stuff, since I'm not really fond of all the built-in possibilities of CE3 flexibility-wise. Network will probably be done the same way. It's just the graphics- and physics-engine that I need mostly. Greets, Rotary Ps. Sorry for lack of updates, I'm currently moving to a new place. I'm watching this forum closely though, so don't hesitate to ask
|
|
|
Post by rotary on Sept 23, 2012 16:51:47 GMT -5
Update: The CE3 Engine is about to receive an update. During discussions about possible fixes an admin pointed me at a possible work-around for the accuracy-issue.. I checked the work-around and it seems to mostly get rid of the problem (it is still there, only slightly visible if you know it). They are still looking into it to fix it permanently in the update.
So proceeding with the logic soon..
Happy regards!
Rotary
|
|