Lunarovich

I think so. It has to do with the compiler LE is using. Anyway, do yoy (or anyone else) could tell me, how do we create now (in LE 3.5) Visual Studio Project?

How do we setup Visual studio project now? Can we use Code::Blocks in Windows?

Thank you. I find it quite disconcerting, as a matter of fact, that you have to use some long and eventually bug prone and complicated code to be able to read simple input event several times in one frame. (BTW, not a single word in API reference about it). It goes against the intuition and philosophy of LE, which I sum up as a meaningful and up to the point simplicity. I have chosen it exactly in order not to have to do such things.

Thanks for the answer! If the part of the current state of the entity depends on the Script:Start(), that part will never be copied to the new entity, since Script:Start() never gets called and copy does not simply make an exact replica of the instance. Agree. However, that happens only in the next application tick. In the current application tick - the one that we copy the entity in -, the script is attached and available (it is not nil). What I find misleading is the fact that a copied entity gets the script without a normal flow of script execution. As a sidenote, there are some other script quirks, at least IMO. For example, one cannot call multiple times Window:MouseHit() inside the same Script:Update() function invocation and expect to get the same results. The first time, call to WIndow:MouseHit() gives a reliable value. Every subsequent time it gives nil, so you cannot make two susequent tests with Window:MouseHit(). Instead, you have to register a value in the variable.

I've run into a situation which seems to be counterintuitive. When I run the following code local entity = self.entity:Copy() end try to access entity's properties that get set in Script:Start() directly afterwards and via entity.script.prop, they are all nil, that is, they don't exist at all. What is more, Script:Start() does not get called at all, even after the tick/frame in question and before the Script:Update() of the next tick/frame. On the contrary, if I run the same code with a line added local entity = self.entity:Copy() entity.script.Start(entity.script) -- here I call manually Script:Start() of the entity everything works as expected. So, shouldn't this behavior be built into LE? I mean, everyone expects that an initialization script runs on entity creation (instancing / copying).

I'm having an issue when I try to execute local entity = self.entity:Copy() I get an error "Script classname sin not found." The self.entity in question has a script named Sin.lua attached. Any ideas? EDIT After renaming and reattaching the script file, everything seems to work for now... Does it have to do with the fact that I've edited it in the external editor?

Great! Thank you very much. Btw 1, I've hit the strange issue of point light reflection on the static surface. I've run test on two different Windows with AMD: desktop and laptop. Namely, if I do a very large zoom on the cast light - the camera still contains the entire reflection in its view -, it starts to flicker on the desktop: the reflection is displayed every other frame. On the laptop, the cast light disappears completely as if there were no light. Btw 2, wouldn't it be also OK to take account of a camera zoom when calculating the visibility of the shadow, as I've suggested in the first place? EDIT Point light flickers even on lower zoom levels when partially inside the camera view. Turning off the occlusion culling solves the problem. Should the light filcker with the occlusion culling enabled? EDIT The central issue of this thread, ie. shadow culling when camera far away and zooms in, does not happen with point light cast shadows. Is this the inconsistent behavior?

Thanks for the answer. Is there a way to set it with Lua? For the current project, I'm not using C++. Anyway, does this setting has anything to do with the zoom or just makes shadows visible from a longer distance?

Alright, this seems like a pretty important issue to me. As it is desirable and expected, directional light shadows are culled (not showed/displayed) when the camera is far away from the object: it has to be within the range of 30m or so, as I've seen so far, in order that shadows get rendered (at least with default light quality). However, when camera is set far away from the object, but zooms in so that it appears very near to the object, shadows are not rendered either. If you think about it, that is a highly unrealistic behavior: Imagine a camera that simulates binoculars. If we look through our binoculars, we are supposed to see the object as if it was near us. In that case, we would see shadows it casts if it is lit by the sun, no matter how far away our binoculars from the object actually are. However, with current LE settings it seems not possible to set cast shadow rendering distance based on the camera zoom level (I'm not sure if it's possible at all, btw - I've read some past threads and no one seems to give a definitive answer). So, a simple improvment on the shadow culling calculation - which would consist in inclusion of dividing camera distance by its zoom level - would be an easy modifcation and more than welcome. At least, IMO. P.S. I've tried setting light's quality to max. It does not solve the issue.

I've just tried to put camera far away with a high zoom value. There are to problems to the solution: Directional light drop shadows are not rendered if the camera is too far away. Is there a way to tell camera to render shadows even if its very far from objects? Vertical lines are not vertical anymore because of the small perspective deformation, so it creates aliased object edges. How do I set higher AA? Thanks!

Hello! I cannot find the user guide anymore. The old URL leads to the API reference page. Is it a bug or some rewrite of guide / reorganization of the web site? In the meantime, where can I find a copy of user guide? Thanks.

Thanks for the tip. Will give it a shot.

Yeah, I understand. It would be nice though to have drop shadows with ortographic rendering. In that way we could mimic in 3D good old isometric RPG-s (Fallout, Arcanum, etc). Those had art made in 3D model editors and code done in 2D engines. I gave an ortographic camera (30, 30, 0) rotation and a FOV clamped to 0.5 - 7.5. Than I've implemented some camera controls - global horizontal xz plane movement and modifyable FOV to mimic zoom - to replicate Fallout 1 camera. It's a real bliss Missing those shadows though...

OK. Thanx. Got it and got it working A side question: does the orthographic camera render drop shadows? Added point lights with shadows in the FOV of camera but nothing seems to happen...

When I try to change a camera mode to Camera.Ortographic, I get a "error in function 'SetProjectionMode'.; argument #2 is 'nil'; 'number' expected." function Script:UpdateWorld() if (window:KeyHit(Key.Space)) then if (self.entity:GetProjectionMode()==Camera.Orthographic) then self.entity:SetProjectionMode(Camera.Perspective) self.entity:SetZoom(1) else self.entity:SetProjectionMode(Camera.Ortographic) self.entity:SetZoom(1) end end end

It works. Thanks! IMHO, this should be done in an automatic fashion by LE or Blender LE exporter.

Every time that I try to import a model from Blender, LE treats it as if it were smoothly shaded. This happens when I do as well when I do not set explicitely shading to flat in Blender. Here is how it looks in Blender: And here is how it looks in LE: Is there a way to get a flat shading when importing from Blender? Thanx!

Hello! I would like to change the default/minimal size of the grid cell so that it does not snap in multiples of 4. Is it possible to have a custom grid cell size so that I can snap objects in multiples of, say, 5? P.S. I know about Increase/Decrease Grid Size options (triggered with [ ]) and I know that I can reduce the grid cell size to 1 or turn off the grid snapping in order to achieve an arbitrary placement of entites.

When I've started, I first did . While doing the series, you should keep open the official guide page as well as the official documentation page and consult it when need be. If you do not know anything about Lua, but know the programming, check first two tutorials on Lua on the official tutorials' page suggested by Josh and, eventually, give a go to the first chapter of the Programming in Lua. And if you are completely new to programming, then you'll have to find some good Lua starter book for non-programmers or at least a decent and comprehensive tutorial. Although the official site probably does not lack any information that you will ever need, you'll have to know exactly what you are looking for and where to find it (approximately ). LE is a very intuitive and elegant framework, and easy to use (at least easier than any other engine I've used so far, and I've tested every major 3D framework), but you'll have to learn the basics of 3D math and basics of LE first. A decent LE getting started guide (with 3D math simplifications maybe and a comprehensive Lua tutorial), official or not official, does not exist yet and, I think, that it would be more than welcome.

I've been working for two days now. I have a basic voxel & chunk generating functions. Voxels are generated with invisible sides occluded. I still haven't implemented invisible chunks occlusion, but would consider my work basically done (for my intents and purposes) when I do it. Namely, from what I've done so far, I've concluded that the number of surfaces is far more important than the number of vertices performancewise. That is, the surface number impacts the performance in a lot more significant way than the number of vertices. Here are facts (relative to my architecture) that lead me to that conclusion. - With a chunk of 64 voxels per chunk dimension, you can easily have over 2 million of voxels with 60fps. - With a chunk size of 16, you can still get away with over million of voxels and get a 60fps. - With a chunk size of 8, you cannot go over 300 thousand and have a 60fps. The problem is that a larger chunk requires a longer time to rebuild. A chunk of size 16 already makes the game visibly stutter for a fraction of a second if you move your character/camera and destroy voxels (I'm destroying them with a single mouse click instantly). The chunk of size 8 gives a barely visible split second stutter on a voxel destruction/rebuild, but suppose that's OK for a normal block building game. So, as I've said, there is directly proportional relation of chunk size and number of chunks you can have in your game. The downside is that there is also a direct proportion between the chunk size and chunk rebuild time. But to get to the point, chunk occlusion algorithm is far more important than vertices collapsing algortihm for flat chunk surfaces, because the performance impact of the number of surfaces is greater than that of the number of vertices. P.S. I'm doing the chunk (re)building in Lua. Maybe a C++ would give better results. (I have a standard edition, but do not feel comfortable yet with C++). P.S. Will send a commented code version as soon as I finish. Or commented version of what I've done so far if I change my mind on the way I'll implement my physics puzzler block manipulation game. P.S. Thanks for the glasses A wayfarer model - my brother, who does the photography, took this photo of me in front of the Zurich lake.

I see that I can Surface::AddVertex. Is there a way to remove a vertex from a sruface or I have to rebuild it from scratch every time I want to remova a vertex? I'm asking it because I'm trying to implement some voxel manipulation framework. At the moment, I rebuild a whole chunk when a single voxel is removed. Is it the only way to do it? Thanks!

Thanks. I knew it was the sci notation, but was puzzled by the fact that other sides that where axis aligned gave int results. What confused me here were leading zeros after the - sign, so I did not know if the number is very small or very large . Thought that we use only signifcant digits. Anyway, thanks again!

Thanks. I did as you suggested. Here are the screenshots: I am printing values with local pos = pickinfo.position System:Print(pos.x .. " " .. pos.y .. " " .. pos.z) directly under the camera pick test.

I'm implementing a camera picking with this code if (window:MouseHit(1)) then local pickinfo = PickInfo() if (self.camera:Pick(context:GetWidth() / 2, context:GetHeight() / 2, pickinfo, 0, true)) then System:Print(pickinfo.position.z) end end and I'm getting really wierd results concerning the pickinfo.position.z (x and y are correct). Here they are This happens only when I'm picking the cube (CSG, but happens with models as well) from the frontside, that is, when I'm facing in the positive z axis direction. When I slowly move the mouse and do the picking, I get different results (already impossible, since the cube side is aligned with the x axis) with impossible values... EDIT: It seems that it happens only when the side of the cube is aligned with the x = 0. Could it be a bug?

OK, thanx. Although it's simple, it would be nice to have this functionality out of the box.