Support and community hang-out spot for Ogre3D
https://forums.ogre3d.org/
They already have both 2d and 3d engines built in:PhilipLB wrote:They say they have a lack of a renderer. Could Ogre3D a choice here? This would be brillant as the editor looks decent.
There's two things that make me wary:Create realistic looking 3D games with the dedicated 3D Engine.
Import 3D models from Max, Maya, Blender, etc. with full animation.
Supports skeleton deforms and blend shapes.
Several light types, with shadow mapping.
Flexible shader & material models.
Render with HDR, anti aliasing and linear color modes.
Post process fog, glow, bloom, color adjustment, etc.
I read somewhere on the site yesterday there current 3D render was very simplistic.Kojack wrote:It's definitely interesting. Single 23MB executable with no installation is the entire engine: IDE, scripting, debugger, game editor, 2d and 3d graphics, 2d and 3d physics, etc.
They already have both 2d and 3d engines built in:PhilipLB wrote:They say they have a lack of a renderer. Could Ogre3D a choice here? This would be brillant as the editor looks decent.There's two things that make me wary:Create realistic looking 3D games with the dedicated 3D Engine.
Import 3D models from Max, Maya, Blender, etc. with full animation.
Supports skeleton deforms and blend shapes.
Several light types, with shadow mapping.
Flexible shader & material models.
Render with HDR, anti aliasing and linear color modes.
Post process fog, glow, bloom, color adjustment, etc.
- custom python inspired scripting (I don't like python, I'd prefer Lua or C#)
- custom physics engine (how does it compare with bullet/physx/havok/newton?)
https://github.com/okamstudio/godot/wiki/gdscriptInitially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.
In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.
The last third party scripting language that was used for shipped games was Squirrel, but it was also dropped too. At that point, it became evident that Godot would work more optimally by using a built-in scripting language, as the following barriers were met:Finally, GDScript was written as a custom solution. The language and interpreter for it ended up being smaller than the binding code itself for Lua and Squirrel, and equally as functional. With time, having a built-in language has proven to be a huge advantage.
- Godot embeds scripts in nodes, most languages are not designed with this in mind.
- Godot uses several built-in data types for 2D and 3D math, script languages do not provide this, and binding them is inefficient.
- Godot uses threads heavily for lifting and initializing data from the net or disk, script interpreters for common languages are not friendly to this.
- Godot already has a memory management model for resources, most script languages provide their own, which resulted in duplicate effort and bugs.
- Binding code is always messy and results in several failure points, unexpected bugs and general unmaintainability.
I can not agree with the slow and complex portion of this.Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code.
):
Code: Select all
OOLUA_PROXY_CLASS(Actor, CallbackTarget)
OOLUA_TYPEDEFS
No_public_constructors
OOLUA_END_TYPES
OOLUA_MEM_FUNC(void, setTransform, const LuaVector3&, const Orientation&)
OOLUA_MEM_FUNC(void, setPosition, const LuaVector3&)
OOLUA_MEM_FUNC(void, setOrientation, const Orientation&)
OOLUA_MEM_FUNC(bool, setupGraphicsModule, const std::string&, const LuaVector3&)
OOLUA_MEM_FUNC(bool, setupPhysicsModule, const PhysicsModuleConfig&)
OOLUA_MEM_FUNC(bool, setupSoundModule)
OOLUA_MEM_FUNC(bool, setupGenerationPriorityModule)
OOLUA_MEM_FUNC(bool, setupCameraModule, const LuaVector3&, const LuaVector3&, const Orientation&, bool)
OOLUA_MEM_FUNC(void, playSoundEvent, const std::string&)
OOLUA_MEM_FUNC(void, move, const LuaVector3&)
OOLUA_MEM_FUNC(void, activateCamera)
OOLUA_CLASS_END
Code: Select all
func _integrate_forces( state ):
var lv = state.get_linear_velocity() # linear velocity
var g = state.get_total_gravity()
var delta = state.get_step()
var d = 1.0 - delta*state.get_total_density()
if (d<0):
d=0
lv += g * delta #apply gravity
var anim = ANIM_FLOOR
var up = -g.normalized() # (up is against gravity)
var vv = up.dot(lv) # vertical velocity
var hv = lv - (up*vv) # horizontal velocity
var hdir = hv.normalized() # horizontal direction
var hspeed = hv.length() #horizontal speed
var floor_velocity
var onfloor = false
if (state.get_contact_count() == 0):
floor_velocity = last_floor_velocity
else:
for i in range(state.get_contact_count()):
if (state.get_contact_local_shape(i) != 1):
continue
onfloor = true
floor_velocity = state.get_contact_collider_velocity_at_pos(i)
break
var dir = Vector3() #where does the player intend to walk to
var cam_xform = get_node("target/camera").get_global_transform()
if (Input.is_action_pressed("move_forward")):
dir+=-cam_xform.basis[2]
if (Input.is_action_pressed("move_backwards")):
dir+=cam_xform.basis[2]
if (Input.is_action_pressed("move_left")):
dir+=-cam_xform.basis[0]
if (Input.is_action_pressed("move_right")):
dir+=cam_xform.basis[0]
Pictures and details:It's a lightmapper, but not really a lightmapper. It bakes light but not to textures. It can handle direct light, diffuse light, specular light, reflections, translucent objects, radiosity, anything! It writes the light information to a compacted octree stored very efficiently inside a texture.
What's the advantage of doing this? that you don't need to do any UV mapping to the objects, you don't have to adjust lightmap resolution for each, you don't have to worry about self-intersection geometry that might bleed light or darkness.