This forum is now closed.
Please join us at the new Lumion Community forum.
Lumion Community
Use your email address and password from the old forum to log in if your account was created before Feb 20 2020.
Otherwise, you will need to create a new Lumion Account at the new forum.

Author Topic: Lumion 2 Build 2 Released  (Read 28850 times)

Re: Lumion 2 Build 2 Released
« Reply #30 on: January 02, 2012, 03:26:10 pm »
January 02, 2012, 03:26:10 pm
No, it's Ferry.
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.

RAD

    Reputation: 32
Re: Lumion 2 Build 2 Released
« Reply #31 on: January 02, 2012, 03:27:31 pm »
January 02, 2012, 03:27:31 pm
   ;)  ty


Re: Lumion 2 Build 2 Released
« Reply #32 on: January 02, 2012, 04:23:48 pm »
January 02, 2012, 04:23:48 pm
One feature I really miss is to be able to export out of a 3d app (i.e 3ds Max), with fbx that supports instancing (for the last 2 versions I think), and then replace them with an object in Lumion.......specifically trees and cars. Placing such things in 3dsmax is a breeze, but a nightmare from hell in Lumion, especially when you consider that terrains are imported as well as there is nearly always a landscape-architect involved in these projects we do here. I have actually still never actually used the native terrain for other things than the bottom of the ocean. This means there is no Auto align either and all axes of rotation mus be manually adjusted.
One way to populate larger areas would be to define one of the imported materials as a scatter'able material, and then adjust density, and maybe define several library objects to scatter on it.

Good point... but of course the importing would get a lot more complex since you would be importing a scene instead of a single object. It's a cool idea though. Maybe some day...

By the way: Didn't you know? Ferry is way above 60 but he just looks very young ;)

I think the first 3D gfx I did with ferry is around 20 years ago... a program called Imagine on an Amiga!


AsplanViak

    Reputation: 2
Re: Lumion 2 Build 2 Released
« Reply #33 on: January 02, 2012, 04:34:28 pm »
January 02, 2012, 04:34:28 pm
Good point... but of course the importing would get a lot more complex since you would be importing a scene instead of a single object. It's a cool idea though. Maybe some day...

You might want to do a poll on this. I wager most users actually import their complete scene every time and update it, not import several smaller parts and elements. One of the reasons for this assumption is Lumion's mysterious lack of proper 3d snapping, and more importantly, lack of a fixed origin for import.
I would also like to see some statistics for Sketchup users regarding wasted "world space" as nearly every person I have encountered using Sketchup, models in positive XY space. They completely disregard  -x and -y thus severely limiting their available float precision for larger files. (We do quite large models here at work for urban planning etc.)
Anyway... workflow-wise, Lumion forces us to export the complete scene from our native applications, so I don't really see the problem, unless you are thinking of how to deal with file formats that don't support instancing? Or am I completely off on a different tangent (I can get carried away sometimes)  ;)

Re: Lumion 2 Build 2 Released
« Reply #34 on: January 02, 2012, 04:53:13 pm »
January 02, 2012, 04:53:13 pm
You might want to do a poll on this. I wager most users actually import their complete scene every time and update it, not import several smaller parts and elements. One of the reasons for this assumption is Lumion's mysterious lack of proper 3d snapping, and more importantly, lack of a fixed origin for import.
I would also like to see some statistics for Sketchup users regarding wasted "world space" as nearly every person I have encountered using Sketchup, models in positive XY space. They completely disregard  -x and -y thus severely limiting their available float precision for larger files. (We do quite large models here at work for urban planning etc.)
Anyway... workflow-wise, Lumion forces us to export the complete scene from our native applications, so I don't really see the problem, unless you are thinking of how to deal with file formats that don't support instancing? Or am I completely off on a different tangent (I can get carried away sometimes)  ;)

The issue right now is just that Lumion imports a model as a single model. When we start importing scenes it would mean Lumion needs to import multiple objects and place them in the scene directly. The second issue with that is we will have to improve to model library because of the vast amount of objects created with a single import. By the way... why not just import one huge model? Is it too big?

markgel

    Reputation: 0
Re: Lumion 2 Build 2 Released
« Reply #35 on: January 03, 2012, 10:00:00 am »
January 03, 2012, 10:00:00 am
hello!where can i download lumion 2.0 free version?

Re: Lumion 2 Build 2 Released
« Reply #36 on: January 03, 2012, 10:08:25 am »
January 03, 2012, 10:08:25 am
Hi markgel, Lumion 2 Free will be released later this month.
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.

AsplanViak

    Reputation: 2
Re: Lumion 2 Build 2 Released
« Reply #37 on: January 03, 2012, 10:14:58 am »
January 03, 2012, 10:14:58 am
The issue right now is just that Lumion imports a model as a single model. When we start importing scenes it would mean Lumion needs to import multiple objects and place them in the scene directly. The second issue with that is we will have to improve to model library because of the vast amount of objects created with a single import. By the way... why not just import one huge model? Is it too big?
Well, you were actually the one that said it would pose an issue with scenes build up of multiple imports (the original issue unless I completely misunderstood), and I just commented that I think most users dump their whole scene file into Lumion in one go anyway, as do I.
From your reply it seems Lumion then totally disregards instancing and objects local transforms from the fbx file, and just imports the triangles into worldspace.....
Is it so much more heavy to keep objects and transforms intact on import? Memory wise it would be better in regards to instancing, but I must admit that probably a lot of users will end up with very complex files as they often aren't aware of the issue of having too many local transforms where they probably should have collapsed a bunch of models into one mesh instead.

As for library stuff, how is this impacted? Are you referring to the import dialogue, or your pre-built asset library?
Making a more user-customizable library would probably help a lot, as the current way of having tons of imported and customized imports of custom vehicles and furniture is rather messy and cumbersome.

AsplanViak

    Reputation: 2
Re: Lumion 2 Build 2 Released
« Reply #38 on: January 03, 2012, 10:18:27 am »
January 03, 2012, 10:18:27 am
Btw, is this maybe the wrong thread to discuss these things? Seems I am the only one discussing Lumion technical issues, and everyone else is talking about your age and lumion free. Should I find another thread maybe? :)

bakbek

    Reputation: 11
Re: Lumion 2 Build 2 Released
« Reply #39 on: January 03, 2012, 11:15:08 am »
January 03, 2012, 11:15:08 am
Btw, is this maybe the wrong thread to discuss these things? Seems I am the only one discussing Lumion technical issues, and everyone else is talking about your age and lumion free. Should I find another thread maybe? :)

Let me jump in and stand at your side then ;)

I feel the same way about importing models / scenes into Lumion. As a matter of fact the current file system is not that good too.

Ideally, each project should get its own folder with the models assets placed inside it for easy transfer to other team members with other lumion installs... pinning it all on the "Lumion 2" folder as is currently is bad. You need to constantly copy it fully to get the files saved to show up and this is hard to manage.

About importing scenes... a unified origin will go a long way. this way we can brake up the big scene into parts - import them one by one - and they will be placed in relation to the origin. Having to eyeball it is not even an option and this is way we just import the big scene as one as is. We might want to animate just parts of it and that can't be done currently. We might want to replace just part of it and that can't be done currently - why force us to always update the complete model that can be very big at times.

Lumion needs some serious work on these file/model management issues

Re: Lumion 2 Build 2 Released
« Reply #40 on: January 03, 2012, 12:07:54 pm »
January 03, 2012, 12:07:54 pm
Is it so much more heavy to keep objects and transforms intact on import? Memory wise it would be better in regards to instancing, but I must admit that probably a lot of users will end up with very complex files as they often aren't aware of the issue of having too many local transforms where they probably should have collapsed a bunch of models into one mesh instead.

Hi AsplanViak, if they made it possible to move/rotate/scale individual surfaces of an imported model, the modified model in Lumion would become out of sync with the original scene in your modelling applications.

The fundamental question is whether we want to make it possible to have out-of-sync models in Lumion, or whether the model in Lumion should always be identical to the model in your modelling application.

Picture this:
Let's say we had individual surface transforms in Lumion, so that every single object would have its own transform set. And now your client is checking out a building that you have prepared in Lumion. Unfortunately, your client isn't satisfied with the way you've designed the kitchen, so based on his feedback, you move/rotate/scale the kitchen cabinets and appliances, and after a few minutes, you've got a very different kitchen and a happy client.

Unfortunately, it's not possible to export the modified model from Lumion to SketchUp (where the construction drawings will be produced), so you end up having to reproduce the changes in the original scene in SketchUp. It's not easy, and it will never be exactly the same as in Lumion, but with a bit of patience you manage to make it look more or less the same as in Lumion.

In the mean time, your client requests some more changes in the living room which you also fix in SketchUp.

You export the whole scene again, and reload it in Lumion.

To your surprise, the kitchen cabinets and the appliances seem to have been offset from the position in SketchUp, and their rotation/scale values are longer correct. And then you realise that the transforms that you and the client made in Lumion are still being applied to the reloaded model.

The problem is that we end up with a bunch of transform sets for each surface which have the potential to get increasingly out of sync and will require that you make a number of decisions on a per-surface basis every time you update and reload your model in your modelling application. We would have:

1) The Lumion transform set (the "base" transforms in Lumion that you can always revert to).
2) The offset from the "base transforms" if you change them (eg, moved/rotated/scaled the kitchen cabinets).
3) The new transform set from the updated SU scene.

After reloading the model, we would then have to highlight each surface that no longer has the same transform set as in #1. And we would probably also need to make it possible to display the original transform set for comparison (as a toggle switch), so that you would get a visual cue as a basis for making the decisions for each surface that is different when reloading your model, for example, should #2 be discarded or kept intact and should #3 override #1?

The reason I believe this approach isn't ideal is that you can't export models from Lumion to your modelling application. Sure, if we allowed individual surface transforms in Lumion you could do more of the design work in Lumion but on the other hand, you would be unable to transfer those changes to your modelling application, and out of sync models would become the norm.

That being said, I do understand why you would like to have the option to move individual surfaces, so if Remko does implement it, this function should not be turned on by default in my opinion :)
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.

Re: Lumion 2 Build 2 Released
« Reply #41 on: January 03, 2012, 12:15:44 pm »
January 03, 2012, 12:15:44 pm
... and more importantly, lack of a fixed origin for import.

About importing scenes... a unified origin will go a long way.

Although this decision isn't in my hands, I agree that there ought to be a "Centre model" option when importing/reloading models. Perhaps they will consider a "Centre model" import option once they implement absolute transform type-ins (as mentioned in an earlier post).
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.

Re: Lumion 2 Build 2 Released
« Reply #42 on: January 03, 2012, 12:35:20 pm »
January 03, 2012, 12:35:20 pm
Is it so much more heavy to keep objects and transforms intact on import? Memory wise it would be better in regards to instancing, but I must admit that probably a lot of users will end up with very complex files as they often aren't aware of the issue of having too many local transforms where they probably should have collapsed a bunch of models into one mesh instead.
I must admit that I don't know if there are other formats than .max that define instances (well, it actually has to be defined as a "reference" model) in a format that Lumion can import, but Artur, our import/export guru knows more about this topic (he's on holiday until Jan 12).

But generally speaking, in real-time CG, duplicated low-poly surfaces that share the same material perform a lot better if you collapse them to a single surface.

However, if you have 100 high-poly surfaces, you'll get a better frame rate if you use instances.

Regarding the use of high-poly "references" in .max files that are imported in Lumion, please check out Stenhock's post:
http://lumion3d.com/forum/index.php?topic=1744.msg10513#msg10513
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.

AsplanViak

    Reputation: 2
Re: Lumion 2 Build 2 Released
« Reply #43 on: January 03, 2012, 03:11:49 pm »
January 03, 2012, 03:11:49 pm
Hi AsplanViak, if they made it possible to move/rotate/scale individual surfaces of an imported model, the modified model in Lumion would become out of sync with the original scene in your modelling applications.

The fundamental question is whether we want to make it possible to have out-of-sync models in Lumion, or whether the model in Lumion should always be identical to the model in your modelling application.

Picture this:
Let's say we had individual surface transforms in Lumion, so that every single object would have its own transform set. And now your client is checking out a building that you have prepared in Lumion. Unfortunately, your client isn't satisfied with the way you've designed the kitchen, so based on his feedback, you move/rotate/scale the kitchen cabinets and appliances, and after a few minutes, you've got a very different kitchen and a happy client.

Unfortunately, it's not possible to export the modified model from Lumion to SketchUp (where the construction drawings will be produced), so you end up having to reproduce the changes in the original scene in SketchUp. It's not easy, and it will never be exactly the same as in Lumion, but with a bit of patience you manage to make it look more or less the same as in Lumion.

In the mean time, your client requests some more changes in the living room which you also fix in SketchUp.

You export the whole scene again, and reload it in Lumion.

To your surprise, the kitchen cabinets and the appliances seem to have been offset from the position in SketchUp, and their rotation/scale values are longer correct. And then you realise that the transforms that you and the client made in Lumion are still being applied to the reloaded model.

The problem is that we end up with a bunch of transform sets for each surface which have the potential to get increasingly out of sync and will require that you make a number of decisions on a per-surface basis every time you update and reload your model in your modelling application. We would have:

1) The Lumion transform set (the "base" transforms in Lumion that you can always revert to).
2) The offset from the "base transforms" if you change them (eg, moved/rotated/scaled the kitchen cabinets).
3) The new transform set from the updated SU scene.

After reloading the model, we would then have to highlight each surface that no longer has the same transform set as in #1. And we would probably also need to make it possible to display the original transform set for comparison (as a toggle switch), so that you would get a visual cue as a basis for making the decisions for each surface that is different when reloading your model, for example, should #2 be discarded or kept intact and should #3 override #1?

The reason I believe this approach isn't ideal is that you can't export models from Lumion to your modelling application. Sure, if we allowed individual surface transforms in Lumion you could do more of the design work in Lumion but on the other hand, you would be unable to transfer those changes to your modelling application, and out of sync models would become the norm.

That being said, I do understand why you would like to have the option to move individual surfaces, so if Remko does implement it, this function should not be turned on by default in my opinion :)

Heh. I never meant for objects to be animated or otherwise translated after import into Lumion, just that their local transforms (axes) stay intact in relation to the idea I proposed where one instance-replaced them inside lumion with whatever library object one wanted (trees\bilboards, characters, props etc.).
Anyway, one would probably never do those changes you suggested inside Lumion, but if we were able to properly place imports (models) to a fixed place, we could split up our scenes so we just reimported the adjusted (in Sketchup\max etc.) kitchen and not the rest.

Re: Lumion 2 Build 2 Released
« Reply #44 on: January 03, 2012, 03:17:53 pm »
January 03, 2012, 03:17:53 pm
I never meant for objects to be animated or otherwise translated after import into Lumion, just that their local transforms (axes) stay intact in relation to the idea I proposed where one instance-replaced them inside lumion with whatever library object one wanted (trees\bilboards, characters, props etc.).

No worries, seems that I over-interpreted your previous posts then :)

if we were able to properly place imports (models) to a fixed place, we could split up our scenes so we just reimported the adjusted (in Sketchup\max etc.) kitchen and not the rest.

Just double-checking, but are you already familiar with the Align command? (CTRL-select objects -> Context menu -> Transformation -> Align)

This command lets you centre selected objects so that their pivot points are at the same position. If you need to move or manipulate one of the overlapping objects, place the mouse cursor above the small overlapping object selection icons and use the mouse wheel (or the Arrowkeys Up/Down) to toggle between the objects.

You can also turn on "Enable Frames Per Second" to see the world origin (0,0,0) as well as to display the position of the object that you are moving.

(Needless to say, I realise that this isn't 100% accurate and won't replace the need for absolute transform type-ins which they want to implement later on)
IMPORTANT: Please do not send private messages and emails to members of staff - unless we specifically ask you to send us sensitive information, for example License Keys.