Posts by jlo

    I've read that vray has incorporated the enscape sky system and enscape has incorporated vray material attributes/integration and that's all I heard so far. Either way, these aren't features that I find important for enscape itself to keep me motivated into the future and as my annual sub comes to an end in a couple of months, I will seriously be looking at both superior alternatives (like unreal engine) and cheaper alternatives such as D5 and I will be making serious decisions then. I would be interested in doing enscape month to month but that price is currently ridiculous especially compared to the annual cost so I'm not really happy about that concept either and I don't know that I want to be locked into enscape for a full 2023. Enscape is great because it's simple and still high quality but it's losing it's edge all around imo.


    If I could roll off the annual into a month to month but still pay the same price without the lock-in then I would probably do it maybe indefinitely but not sure I want to be locked into the annual term as a forced option.

    you mean like stars... That have no detail anyway... For a ceiling perhaps? Also, the source picture (me) is low quality and the emissive material is purposelessly blown out to make the point but obviously it works fine when setup up properly just like when using it for phones or TV screens etc... so I don't really get the complaint. It seems a perfectly valid workflow and option.

    Just skimming through this thread, I agree with Paul in that I like to do all my work in SKP and I do not like to work in enscape itself simply due to then only needing 1 place to edit the source material if needed and I love the real time integration between the 2 programs. Having said that, I would extremely prefer the option of having higher quality renders which included additional features or superior quality. People like Rdtest1 could use a lower quality option to get quicker renders and others can add functionality/features/quality knowing that that would require longer render times. Back in my CPU rendering days, Ive had renders take multiple days so something that took 0-5 min is fantastic and if I needed it quicker - turning down the options would give me that flexibility needed. The problem comes when I need the ability and have no options but to look at other products.

    As far as vray integration, I don't need to use both products and am not interested in doing so. Integration with vray materials might be nice (or creating materials algorithmically) but I'm happy with my own library and I think the benefit would be minimal for me but I'll keep an open mind on that portion. Currently, it's good from a business perspective but not yet shown from the consumer perspective.

    The driver has been updated to the most current AMD PRO driver downloaded today (9/24/22.) from their website. Enscape was upgraded to 3.4.1+85781. SKP instantly crashes when placing an enscape object such as a light sphere into an empty model and without enscape itself running. Feedback already sent.


    Maybe the enscape lights are proxy objects themselves and the same problem Paul is having?

    Im getting crashing as of today on the 2 variations of 3.4 that i have. Im reverting back to 3.3.1 as it seems stable for now and i need to output for a job. Should i try the version posted above after the project?


    my scenario is as soon as i create an enscape object such as a light sphere - it crashes skp immediately (enscape does not need to be running). This occurs even with no model open (template only).

    I would -not- think the same exe would work for both. I would assume a seperate choosable file output for each platform (the user would choose which output they wanted to get) since both engines are different. This then may allow the devs to have a seperate code package output per port instead of being a universal exe and minimizing code creation. It would also help with the code bridge point only at the point of outputting the exe. Theoretically then if a PC user output a mac version then maybe that pc user wouldnt even be able to validate it worked properly unless they migrated the file to a mac themselves before sending to a client but ultimately that would allow control/workflow to the creator instead of having it be a concern and ability of the client (and potentially not even being able to do it at all as it is now).

    "Stand-alone exports from a windows machine are still in the .exe format "


    Hi, and thanks, Dan,
    Can they be adapted to allow either a PC or mac output as a feature request (which I did just make one yesterday on the forum)? Separately, is it technically possible for this code to be created or is it a non-starter from a tech viability aspect?

    Asking an interior designer or architect to use vmware is a non starter (especially noting some are barely computer viable/capable in the first place) and the web standalone isn't great quality comparatively.

    Both of you guys are missing the point. There is a difference between a bug or not working as intended operation and a feature which is OPTIONAL FUNCTIONALITY. The way enscape has applied it is standard html5 coding and looks to be using that basic spec. I even showed that code that does NOT use enscape but is built into the html spec. It's the same. The way you guys may have used it elsewhere in specialized software to add functionality from what html5 offers natively. It's IRRELEVANT from how many panos youve done prior or the options of that -different- software - it doesn't make it a bug. It's a feature/option.